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.
The Pain That Is GitHub Actions
41–50 of 584 posts
Re: The Pain That Is GitHub Actions
#42Re: 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.
Re: The Pain That Is GitHub Actions
#44GHA 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`.
> 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
#45I 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.
// Luckily still a gitlab user, but recently forced to Microsoft Teams and office.
Re: The Pain That Is GitHub Actions
#46Genuine 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?
Re: The Pain That Is GitHub Actions
#47Genuine 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?
Re: The Pain That Is GitHub Actions
#48tldr 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.
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.
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”.
Re: The Pain That Is GitHub Actions
#50GHA feels like a discontinued product that people use so they can’t switch it off.