4 ms·

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

by tevon 2y ago

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.

8n4vidtmkvmk 2y ago
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.
- masklinn 2y ago
  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).
  - oefrha 2y ago
    > 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.
    - masklinn 2y ago
      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.
- arccy 2y ago
  git commit --allow-empty -m "bump ci" unless your pipeline does magic with trying to detect changed files
  - mdaniel 2y ago
    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?
    - arccy 2y ago
      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...
  - 8n4vidtmkvmk 2y ago
    I use Mercurial + hg-git like a weirdo. Not sure if Mercurial supports empty commits, I don't think it does.
    - mdaniel 2y ago
      I was curious and it certainly appears that you are right $ hg init $ hg commit -m"initial" nothing changed
      - 8n4vidtmkvmk 2y ago
        Turns out it does, actually. hg ci -m "empty commit" --config ui.allowemptycommit=1 From https://stackoverflow.com/a/71428853 https://stackoverflow.com/a/71428853. I tried it to confirm.
nunez 2y ago
Biggest pet peeve of GHA by a country mile.
pavon 2y ago
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 #"

by tevon 2y ago

8n4vidtmkvmk 2y ago

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.

masklinn 2y ago
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).
- oefrha 2y ago
  > 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.
  - masklinn 2y ago
    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.
arccy 2y ago
git commit --allow-empty -m "bump ci" unless your pipeline does magic with trying to detect changed files
- mdaniel 2y ago
  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?
  - arccy 2y ago
    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...
- 8n4vidtmkvmk 2y ago
  I use Mercurial + hg-git like a weirdo. Not sure if Mercurial supports empty commits, I don't think it does.
  - mdaniel 2y ago
    I was curious and it certainly appears that you are right $ hg init $ hg commit -m"initial" nothing changed
    - 8n4vidtmkvmk 2y ago
      Turns out it does, actually. hg ci -m "empty commit" --config ui.allowemptycommit=1 From https://stackoverflow.com/a/71428853 https://stackoverflow.com/a/71428853. I tried it to confirm.

nunez 2y ago

Biggest pet peeve of GHA by a country mile.

pavon 2y ago

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 #"