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

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.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

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

Search: