Live data from Hacker News

I hate GitHub Actions with passion

xlii.space

341–347 of 347 posts

Re: I hate GitHub Actions with passion

#341

Earlier quoted context omitted.

What do you mean? Simple env prints get masked as *** in logs I guess one can always just echo the secret to a file and upload-artifact it

Unless you've got something sanitizing env prints in your logs, no, they don't get masked. I've leaked secrets accidentally while debugging environment variable issues. Of course the bigger side of the issue is that anyone who can run code in the CI context can view all data in the CI context. So if an untrusted dev can write a build script that executes with secrets in the environment, they can leak those secrets. C…

Secrets that you store in github actions secrets?

Re: I hate GitHub Actions with passion

#342
Run your own server for GitHub Actions. There is a simple library they have you install so your runner gets registered with your repo. Then you can SSH in whenever a job fails. This lets you fully inspect the state, and to execute one-off commands to test theories. It’s a much faster way to iterate.

Re: I hate GitHub Actions with passion

#343

I think this post accurately isolates the single main issue with GitHub Actions, i.e. the lack of a tight feedback loop. Pushing and waiting for completion on what's often a very simple failure mode is frustrating. Others have pointed out that there are architectural steps you can take to minimize this pain, like keeping all CI operations isolated within scripts that can be run locally (and treating GitHub Actions fe…

I've standardized on getting github actions to create/pull a docker image and run build/test inside that. So if something goes wrong I have a decent live debug environment that's very similar to what github actions is running. For what it's worth.

I’ve VNCed into CI to debug selenium tests failing because of platform font and scrollbar rendering. I never really thought about doing that locally in a docker container, but it definitely wouldn’t be convenient to always run those tests locally in a docker container. I guess having an option to would sort of simplify debugging, but I’d still have to VNC into the docker container I think

Re: I hate GitHub Actions with passion

#345

Earlier quoted context omitted.

Unless you've got something sanitizing env prints in your logs, no, they don't get masked. I've leaked secrets accidentally while debugging environment variable issues. Of course the bigger side of the issue is that anyone who can run code in the CI context can view all data in the CI context. So if an untrusted dev can write a build script that executes with secrets in the environment, they can leak those secrets. C…

Secrets that you store in github actions secrets?

Yes. I've done it. That's why there is an "approve and run" button when the PR comes from another repo. So that the maintainers can check if the PR is trying to exfiltrate secrets... or do other bad things of course.

The whole point of the github action secrets is that they are accessible by the CI when needed. Which means they are accessible. It's just a convenient way to store the secret in such a way that it is not completely public. But you still have to trust github and your maintainers.

Re: I hate GitHub Actions with passion

#346

Earlier quoted context omitted.

Uncovering secrets is usually trivial. `printenv` in a build script does that pretty reliably.

What do you mean? Simple env prints get masked as *** in logs I guess one can always just echo the secret to a file and upload-artifact it

Like masking would work against anything but accidents.

  printenv | base64

Re: I hate GitHub Actions with passion

#347
post #115

The love for Github Actions dissipated fast, it wasn't that long ago we had to read about how amazing Github Actions where. What changed?

I think it made CI management more accessible. Before that, most people would avoid Jenkins and probably never try Buildbot (because devs typically don't want to spend any time learning tools). Devs would require "devops" to do the CI stuff. Again, mostly because they couldn't be arsed to make it themselves, but also because it required setting up a machine (do you self-host, do you use a VPS?). Then came tools like…

I'd like to point out that CircleCI is typically faster (and more consistent) than GH Actions, and also offers a free tier (with more free build credits for opensource projects: https://circleci.com/open-source/)

Personally I believe that GH Actions' adoption was mostly a case of "we already use github as our VCS, so we get Actions for free with our MS licenses" combined with "hey, we can easily use all those Actions that people put online" (with all the security and compliancy issues that come with such a YOLO mindset lol)

(Disclaimer: i work for CircleCI)

Post reply on HN