Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I call writing GitHub Actions "Search and Deploy", constantly pushing to a branch to get an action to run is a terrible pattern...

You'd think, especially with the deep VS Code integration, they'd have at least a basic sanity-check locally, even if not running the full pipeline.



Not just me then? I was trying to fix a GitHub action just today but I have no clue how I'm supposed to tear it, so I just keep making tiny changes and pushing.... Not a good system but I'm still within the free tier so I'm willing to put up with it I guess.


I think it’s everyone, debugging GH actions is absolute hell, and it gets terrifying when the action interacts with the world (e.g. creating and deploying packages to a registry).


> it gets terrifying when the action interacts with the world (e.g. creating and deploying packages to a registry).

To be fair, testing actions with side effects on the wider world is terrifying even if you’re running it locally, maybe more so because your nonstandard local environment may have surprises (e.g. an env var you set then forgot) while the remote environment mostly only has stuff you set/installed explicitly, and you can be sloppier (e.g. accidentally running ./deploy when you wanted to run ./test). That part isn’t a GH Actions problem.


Locally it is much easier to set up and validate test environments, or neuter some of the pipeline to test things out and ensure the rest produces expected results (in fact I usually dry-run by default and require a file or envvar to “real run”). Especially as some jobs (rightfully) refuse to run in PRs.


    git commit --allow-empty -m "bump ci"
unless your pipeline does magic with trying to detect changed files


If this is to troubleshoot non-code related failures (perm issues, connection timed out, whatever influences success that doesn't require a code change) then surely the repo's history would benefit from one just clicking "Re-run Job", or its equivalent $(gh ...) invocation, right?


not necessarily, rerun job will most likely use the fully resolved dependency graph of your actions (or equivalent), a fresh run will re-resolve them (e.g. you pinned to @1 vs the specific version like @1.2.3 of a dep).

the history problem goes away if you always enforce squash merge...


I use Mercurial + hg-git like a weirdo. Not sure if Mercurial supports empty commits, I don't think it does.


I was curious and it certainly appears that you are right

  $ hg init
  $ hg commit -m"initial"
  nothing changed


Turns out it does, actually.

    hg ci -m "empty commit" --config ui.allowemptycommit=1

From https://stackoverflow.com/a/71428853. I tried it to confirm.


Ah yes, I have a git alias created specifically for the "we don't know what it does until we push it" world of CI:

> yolo = "!git commit --all --amend --no-edit && git push --force #"


Biggest pet peeve of GHA by a country mile.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: