Live data from Hacker News

The Pain That Is GitHub Actions

feldera.com

41–50 of 584 posts

Re: The Pain That Is GitHub Actions

#41

I wonder if the complexity of fixing trivial code mistakes in CI is worth it compared to catching them in a pre-commit hook.

Unfortunately people will use --no-verify to bypass hooks.

I don't understand commit hooks - they're like binding a macro to the MS Word save button to make it conditional.

Re: The Pain That Is GitHub Actions

#43

> A few days ago, someone compromised a popular GitHub Action. The response? "Just pin your dependencies to a hash." Except as comments also pointed out, almost no one does. I'm surprised nobody has mentioned dependabot yet. It automates this, keeping action dependencies pinned by hash automatically whilst also bringing in stable upgrades.

Wasn’t part of the problem though that renovate was automatically upgrading people to the compromised hash? Or is that just the fault of people configuring it to be too aggressive with upgrades?

Re: The Pain That Is GitHub Actions

#44

GHA is full of such obure behaviours. One I recently discovered is that one action can not trigger another: If one action pushes a tag to the repo, `on:tag` does not trigger. The workaround apparently is to make the first action push the tag using a custom SSH key, which magically has the ability to trigger `on:tag`.

https://docs.github.com/en/actions/security-for-github-actio...

> When you use the repository's GITHUB_TOKEN to perform tasks, events triggered by the GITHUB_TOKEN, with the exception of `workflow_dispatch` and `repository_dispatch`, will not create a new workflow run.

It has bitten me in the rear before too. I use this pattern a lot when I publish a new version, which tags a piece of code and then marks assets as part of that version (for provenance reasons I cannot rebuild code).

Re: The Pain That Is GitHub Actions

#45

I worked at companies using Gitlab for a decade, and got familiar with runners. Recently switched to a company using Github, and assumed I'd be blown away by their offering because of their size. Well, I was, but not in the way I'd hoped. They're absolutely awful in comparison, and I'm beyond confused how it got to that state. If I were running a company and had to choose between the two, I'd pick Gitlab every time j…

Glad I’m not the only one. GitLab runners just make sense to me. A container you run scripts in. I have some GitHub actions for some side projects and it just seems so much more confusing to setup for some reason.

So Github was really the perfect acquisation for the Microsoft portfolio. Applications with a big market share that are technically inferior to the competition.

// Luckily still a gitlab user, but recently forced to Microsoft Teams and office.

Re: The Pain That Is GitHub Actions

#46
post #33

Genuine question: what's the GitLab equivalent of GitHub Actions? I'm using GitHub Actions to easily reuse some predefined job setup (like installing a certain Python version on Linux, macOS, Windows runners). For these tyoe of tasks, I find GitHub actions very useful and convenient. If you want to reuse predefined jobs, written by someone else, with GitLab CI/CD, what can I use?

CI/CD Components: https://docs.gitlab.com/ci/components/ (an evolution of CI/CD templates).

Re: The Pain That Is GitHub Actions

#47
post #33

Genuine question: what's the GitLab equivalent of GitHub Actions? I'm using GitHub Actions to easily reuse some predefined job setup (like installing a certain Python version on Linux, macOS, Windows runners). For these tyoe of tasks, I find GitHub actions very useful and convenient. If you want to reuse predefined jobs, written by someone else, with GitLab CI/CD, what can I use?

For reusing pieces of existing pipelines I think `include` would be appropriate, especially `remote` variant:

https://docs.gitlab.com/ci/yaml/#includeremote

Re: The Pain That Is GitHub Actions

#48
post #7

tldr but: don't use GitHub Actions. Its a mess, the availability is often atrocious, and the UI around it is _still_ as clunky as when they first rolled it out many years ago. There are better solutions out there.

> There are better solutions out there.

And what are those?

Re: The Pain That Is GitHub Actions

#49

> A few days ago, someone compromised a popular GitHub Action. The response? "Just pin your dependencies to a hash." Except as comments also pointed out, almost no one does. I'm surprised nobody has mentioned dependabot yet. It automates this, keeping action dependencies pinned by hash automatically whilst also bringing in stable upgrades.

Well but that’s the problem. You cannot fully automate this. You have to manually check the diff of each dependency and only accept the dependabot PR if the changes are safe.

The only automation that I know of is cargo vet. Although it doesn’t work for GitHub Actions, the idea sounds useful. Basically, vet allows people who trust each other to vet updates. So one person verifies the diff and then approves the changes. Next, everyone who trusts this person can update the dependency automatically since it has been “vetted”.

[1]: https://github.com/mozilla/cargo-vet

Post reply on HN