GitHub Actions debugging tip: connect to the running build with ssh

debug_github_actions.md

GitHub Actions debugging tip: You can connect to the running build with ssh and get a shell within the GitHub Actions runner VM.

The recommended approach is to run the build in a PR in your own fork and make only temporary changes to enable the ssh shell. GitHub Actions runs within your own fork when you open a PR to your own fork. Before opening the PR, it's useful to sync your fork's master branch with origin/master. Please check instructions for "Personal GitHub Actions CI" in the dev mailing list archives.

Here's an example of SSH debugging I have: lhotari/pulsar-helm-chart#1 . I removed all other GitHub Actions workflows and added this action step to the workflow where I wanted to connect with ssh:

      - name: Setup upterm session
        uses: lhotari/action-upterm@v1
        with:
          limit-access-to-actor: true 

You can remove limit-access-to-actor: true to allow anyone to connect. The authentication is made by your ssh public key registered in GitHub. After the build starts running, the action will print out the connection address. Here's an example:

Adding actor "lhotari" to allowed users.
Fetching SSH keys registered with GitHub profiles: lhotari
Fetched 2 ssh public keys
Creating a new session. Connecting to upterm server ssh://uptermd.upterm.dev:22
Created new session successfully
Entering main loop
=== CSHTNSXPCJ3IRT3NM6UX                                                                 
Command:                tmux new -s upterm -x 132 -y 43                                 
Force Command:          tmux attach -t upterm                                           
Host:                   ssh://uptermd.upterm.dev:22                                     

SSH Session:            ssh cShTnSXPcj3iRT3nM6ux:[email protected]

the ssh connection can be made by running ssh cShTnSXPcj3iRT3nM6ux:[email protected] (copy-paste from the log) . After connecting, You can get the build to continue with sudo touch /continue command. The shell will terminate when the build completes. If you want to keep it running, add another step in the GitHub Actions workflow to wait:

      - name: Wait 1 hour
        run: sleep 3600

There are more details about action at https://github.com/marketplace/actions/debugging-with-ssh .

personal_github_ci.md

Here are instructions to use your personal CI on GitHub.

1. Push your intended pull request changes to a new branch in your fork (the usual way you do it).
2. Open a pull request to your own fork.

A.) These are the instructions for CLI:

Install GitHub CLI from https://cli.github.com/ and configure it. With GH CLI, there's an easy way to open the PR to your own fork with a single command:

gh pr create --repo=your_github_id/pulsar --base master --head
your-pr-branch -f

B.) You can also create a PR to your own fork in the GitHub UI when opening a new PR. To do so, first click on "compare across forks" and then choose your own fork as both the fork repository and head repository.

Notice: It's worth keeping your master branch in sync with apache/pulsar's master so that the PR diff will be reasonable in your own fork.

Here's one way to sync your fork's master branch with apache/pulsar's master branch: Let's say if you have git remotes called "upstream" for apache/pulsar and "forked" for your fork, with these commands, you synchronize your fork's remote master branch with apache/pulsar's master branch:

# replace "upstream" with the name of the git remote for apache/pulsar
# replace "forked" with the name of the git remote for your fork of pulsar
git fetch upstream
git push -f forked upstream/master:master

When you finally want to create a PR to apache/pulsar, it can be started from the command line (this will open a browser for filling in the PR details):

gh pr create --repo=apache/pulsar --base master --head your-pr-branch --web

I hope this helps in getting started with your personal Pulsar CI so that you can help reduce the load on actual Pulsar CI.