[embedding-shape]

I've seen people spend something like 2 hours fixing something that can be fixed in minutes if you had a normal feedback cycle instead of the 5 minute "change > commit > push > wait > see results" feedback cycle GitHub Action forces people into. It's baffling until you realize Microsoft charges per usage, so why fix it? I guess the baffling part is how developers put up with it anyways.

[Storment33]

Does not sound like a GitHub failure, sounds it is the company's failure. They haven't invested in the developer experience and they have developers who cannot run stuff locally and are having to push to CI in order to get feedback.

[IshKebab]

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 of that!

[Storment33]

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 GitHub, if I the correct credentials in my env. It is all automated(which I developed/tested locally) but I can break glass if needed.

[IshKebab]

> 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.

[Storment33]

I agree there is stuff you can't test locally, but in my experience people most of the time are complaining about stuff they should have local feedback loops for such as compiling, testing, end to end testing etc.

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"`.

[embedding-shape]

Can't do much about that when there is something you're troubleshooting about the CI platform itself. Say you're troubleshooting why the deployment doesn't work, somehow got the environment variable wrong for whatever reason. So you edit and add a "env | sort" before that, commit it, push it, so on. With "rebuilt with ssh", you literally are inside the "job" as it runs.

[Storment33]

Yes you can't really debug CI specific stuff locally, like if your setting up build caching or something. But it seems like 90%+ of the time people are complaining about builds/tests that should have local feedback loops.

[embedding-shape]

Yeah, fair point, I see that a lot in the wild too. I guess I kind of assumed we all here had internalized the practice of isolating everything into one command that runs remotely, like "make test" or whatever, rather than what some people do and put entire shellscripts-but-yaml in their pipeline configs.

[Storment33]

Yeah everytime I see logic in YAML I cringe. Trying at work to get people to use a task runner or even call out to scripts was a fight...