61–67 of 67 posts
Why SSH to the build agent when you can run your actions locally using the excellent https://github.com/nektos/act
What I wish is github codespaces could just do this out of the box, at least for a specific action/runner.
Earlier quoted context omitted.
You can't run a GitHub CI pipeline locally (in general; there are some projects to try but they're limited). Even if you make as much of it runnable locally as possible (which you should) you're inevitably going to end up debugging some stuff by making commits and pushing them. Release automation. Test reporting. Artifact upload. Pipeline triggers. Permissions. Count yourself lucky you've never had to deal with any o…
Yes there are a few things you can't do locally. But the vast majority of complaints I see 90%+ are for builds/tests etc that should have the same local feedback loops. CI shouldn't be anything special, it should be a 'shell as a service' with some privileged credentials for pushing artefacts. > Release automation. Test reporting. Artifact upload. Those I can actually all do locally for my open source projects on Git…
Maybe I wasn't clear enough in my description, but you definitely can't locally do things like automatically creating a release in a Github workflow, sending test results as a comment to PRs automatically and uploading CI pipeline artifacts locally. Those all intrinsically require running in Github CI.
Earlier quoted context omitted.
While I get some stuff you can't test locally, like 90%+ of complaints I see are for builds/tests. Which is really a failure of the engineers for not having a local feedback loop. I am of the opinion you should be able to deploy from your machine, just you do not have the permissions to normally. So that if CI ever goes down and you need to push an emergency fix or something you can break glass if needed.
If you cannot build and run the application locally, I think there is something seriously, seriously wrong at the company. 90% of my day involves sitting in PHP storm with a debugger attached, introspecting whatever I need to. If I had to rely on even print statements being shit out on someone else's machine I don't know that I could be productive.
Earlier quoted context omitted.
Yes there are a few things you can't do locally. But the vast majority of complaints I see 90%+ are for builds/tests etc that should have the same local feedback loops. CI shouldn't be anything special, it should be a 'shell as a service' with some privileged credentials for pushing artefacts. > Release automation. Test reporting. Artifact upload. Those I can actually all do locally for my open source projects on Git…
> Those I can actually all do locally for my open source projects on GitHub Maybe I wasn't clear enough in my description, but you definitely can't locally do things like automatically creating a release in a Github workflow, sending test results as a comment to PRs automatically and uploading CI pipeline artifacts locally. Those all intrinsically require running in Github CI.
You give some good examples and I agree they is CI specific stuff that can only be really tested on CI, but it a subset of what I generally see people complaining about.
> can't locally do things like automatically creating a release in a Github workflow, sending test results as a comment to PRs automatically and uploading CI pipeline artifacts locally.
> uploading CI pipeline artifacts locally
I actually testing this locally before opening up a pull request to add it. I just have my workflow call out to a make target, so I can do the same locally if I have the right credentials using the same make target.
E.g. this workflow trigger on a release.
```yaml name: Continuous Delivery (CD)
on: release: types: [published]
# https://docs.github.com/en/actions/using-jobs/assigning-perm... permissions: contents: write packages: write
jobs: publish-binary: name: Publish Binary runs-on: ${{ matrix.architecture }} strategy: matrix: architecture: [ubuntu-24.04, ubuntu-24.04-arm] steps: - name: Checkout code. uses: actions/checkout@8e8c483db84b4bee98b60c0593521ed34d9990e8 # v6.0.1 - name: Setup Nix. uses: cachix/install-nix-action@4e002c8ec80594ecd40e759629461e26c8abed15 # v31.9.0 - name: Publish binary. run: nix develop -c make publish-binary RELEASE="${GITHUB_REF_NAME}" env: GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} # This token is provided by GitHub Actions. ```
Which after building the binary calls this script
```bash #!/usr/bin/env sh
set -o errexit set -o xtrace
if [ "$#" -ne 2 ]; then echo "Usage: $0 RELEASE_TAG TARGET" echo "$#" exit 1 fi
RELEASE="$1" TARGET="$2"
tar -czvf "${TARGET}.tar.gz" -C "target/${TARGET}/release" "clean_git_history" gh release upload "${RELEASE}" "${TARGET}.tar.gz" rm "${TARGET}.tar.gz" ```
So I was able to test large parts of this locally first via `make publish-binary RELEASE="test-release"`.
I solved it by adding a simple Tailscale action to handle failure. It creates an ephemeral instance and waits for connections for 3 minutes. Then it loops while there's an active SSH session present. It's that simple: https://gist.github.com/Cyberax/9edbde51380bf7e1b298245464a2... and it saved me _hours_ of debug time. I've moved all my CI/CD to use Taskfiles inside a Docker container since then, so my local environm…
That the entire ecosystem seems to have moved to GitHub Actions is such a loss for productivity. I remember when CircleCI first launched, and you could "Rebuild with SSH" which gave you a bash command to connect to the running instance whenever you wanted, was such a no-brainer, and I'm sure why many of us ended up using CircleCI for years. Eventually CircleCI became too expensive, but I still thought that if other s…
That the entire ecosystem seems to have moved to GitHub Actions is such a loss for productivity. I remember when CircleCI first launched, and you could "Rebuild with SSH" which gave you a bash command to connect to the running instance whenever you wanted, was such a no-brainer, and I'm sure why many of us ended up using CircleCI for years. Eventually CircleCI became too expensive, but I still thought that if other s…