Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I'll think twice before using GitHub Actions again

ninkovic.dev

Post reply on HN
Print view View original

211–220 of 284 posts

Re: I'll think twice before using GitHub Actions again

#211

Post by dijit »

reshlo wrote: post #206
plagiarist wrote: post #106

Earlier quoted context omitted.

I decided it was a bad thing when they sent password reset emails to addresses given by unauthenticated users. Not that I ever used them. But now it is a hard no, permanently. They have since had other also severe CVEs. That has made me feel pretty confident in my decision.

If password reset emails shouldn’t be sent to unauthenticated users, how would users reset their passwords?

there was a pretty bad bug (though I think it was a rails footgun)- that allowed you to append an arbitrary email to the reset request.

The only difficult part for the attacker was finding an email address that was used by the target; though thats hsually the same as you use for git commits; and gitlab “handily” has an email address assigned to each user-id incrementing from 1;

Usually low numbers are admins, so, a pretty big attack vector when combined.

Re: I'll think twice before using GitHub Actions again

#212

Post by masklinn »

oefrha wrote: post #40
masklinn wrote: post #31

Earlier quoted context omitted.

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 explici…

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.

Re: I'll think twice before using GitHub Actions again

#213

Post by fuzzy2 »

I hate GitHub Actions, and I hate Azure Pipelines, which are basically the same. I especially hate that GitHub Actions has the worst documentation.

However, I’ve come full circle on this topic. My current position is that you must go all-in with a given CI platform, or forego the benefits it offers. So all my pipelines use all features, to offer a great experience for devs relying on them: Fast, reproducible, steps that are easy to reason about, useful parameters for runs, ...

Re: I'll think twice before using GitHub Actions again

#214

Post by OldOneEye »

hardwaresofton wrote: post #136
0xbadcafebee wrote: post #96

Earlier quoted context omitted.

100%. The ci/cd job should be nothing more than a wrapper around the actual logic which is code in your repo. I write a script called `deploy.sh` which is my wrapper for my ci/cd jobs. It takes options and uses those options to find the piece of code to run. The ci/cd job can be parameterized or matrixed. The eventually-run individual jobs have arguments, and those are passed to deploy.sh. Secrets/environment variabl…

Hey if you’ve never heard of it consider using just[0], it’s a better makefile and supports shell scripting explicitly (so at least equivalent in power, though so is Make) [0]: https://github.com/casey/just

I discovered Just with a similar comment in Hacker News and I want to add my +1.

It is so much better to run scripts with Just than it is doing it with Make. And although I frankly tend to prefer using a bash script directly (much as described by the parent commenter), Just is much less terrible than Make.

Now the only problem is convincing teams to stop following the Make dogma, because it is so massively ingrained and it has so many probems and weirdnesses that just don't add anything if you just want a command executor.

The PHONY stuff, the variable scaping, the every-line-is-a-separate-shell, and just a lot of stuff that don't help at all.

Re: I'll think twice before using GitHub Actions again

#215

Post by xinayder »

lolinder wrote: post #82
xinayder wrote: post #60

I tried to use GitHub Actions on Forgejo and... It's so much worse than using an actual CI pipeline. With Woodpecker/Jenkins you know exactly what your pipeline is doing. With GitHub actions, not even the developers of the actions themselves know what the runner does.

> use GitHub Actions on Forgejo What does this even mean? Are you talking about Forgejo Actions, or are you somehow hosting your code on a Forgejo instance but running CI through GitHub? > With Woodpecker/Jenkins you know exactly what your pipeline is doing. If you wrote it from the ground up, sure. On the other hand, I've inherited Jenkins pipelines that were written years before I got there and involved three to fo…

> What does this even mean? Are you talking about Forgejo Actions, or are you somehow hosting your code on a Forgejo instance but running CI through GitHub?

yes, Forgejo Actions which is supposed to be a drop in replacement for GH Actions. You can say they're different things but the general idea and level of complexity is the same.

Re: I'll think twice before using GitHub Actions again

#216

Post by Lutger »

maccard wrote: post #36
jicea wrote: post #27

Earlier quoted context omitted.

I don't understand why this is not the evident approach for everyone writing GitHub Actions/GitLab CI/CD yaml etc.... I've struggled in some teams to explained why it's better to extract your command in scripts (ShellCheck on it, scripts are simple to run locally etc...) instead of writing a Frankenstein of YAML and shell commands. I hope someday to find an authoritative guidelines on writing pipeline that promote th…

To make the thing actually fast at scale, a lot of the logic ends up being specific to the provider; requiring tokens, artifacts etc that aren't available locally. You end up with something that tries to detect if you're running locally or in CI, and then you end up in exactly the same situation.

You are right, and this is where a little bit of engineering comes in. Push as much of the logic to scripts (either shell or python or whatever) that you can run locally. Perhaps in docker, whatever. All the token, variables, artifacts etc should act as inputs or parameters to your scripts. You have several mechanisms at your disposal, command line arguments, environment variables, config files, etc. Those are all well understood, universal, language and environment agnostic, to an extent.

The trick is to NOT have your script depend on the specifics of the environment, but reverse the dependency. So replace all `If CI then Run X else if Local Run Y` with the ability to configure the script to run X or Y, then let the CI configure X and local configure Y. For example.

I'm not saying it is always easy and obvious. For bigger builds, you often really want caching and have shitloads of secrets and configurations going on. You want to only build what is needed, so you need something like a DAG. It can get complex fast. The trick is making it only as complex as it needs be, and only as reusable as and when it is actually re-used.

Re: I'll think twice before using GitHub Actions again

#217

Post by surajrmal »

slt2021 wrote: post #187
dpkirchner wrote: post #185

Earlier quoted context omitted.

This all reminds me of the systemd ini-like syntax vs shell scripts debate. Shell scripts are superior, of course, but they do require deeper knowledge of unix-like systems.

yeah if you author CI jobs, you should know linux, otherwise a person should not even touch the CI system with 10ft pole

I've been working with Linux since I was 10 (I'm much older now), and I still don't think I "know Linux". The upper bound on understanding it is incredibly high. Where do you draw the line?

Re: I'll think twice before using GitHub Actions again

#218

Post by the_gipsy »

In my newest hobby project, I decided to bite the bullet and use the flake.nix as single source of truth. And it's surprisingly fast! I used cargo-crane to cache rust deps. This also works locally just running "nix flake check". Much better than dealing with github actions, caches, and whatnot.

Apart from the nix gh action that just runs "nix flake check", the only other actions are for making a github release on certain tags, and uploading release artifacts - which is something that should be built-in IMO.

Re: I'll think twice before using GitHub Actions again

#219

Post by arccy »

mdaniel wrote: post #162
arccy wrote: post #73

Earlier quoted context omitted.

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...

Re: I'll think twice before using GitHub Actions again

#220

Post by mongol »

eru wrote: post #179
mongol wrote: post #113

Earlier quoted context omitted.

Is this really the job of an enterprise architect? To dig into the details of a devops team's mess?

The job of senior people should mostly be to make sure the organisation runs smoothly. If no one else is doing anything about the mess, then it falls to the senior person to sort it out. As a rule of thumb: - Ideally your people do the Right Thing by themselves by the magic of 'leadership'. - Second best: you chase the people to do the Right Thing. - Third: you as the senior person do the Right Thing. - Least ideal:…

Where I work, which granted is a very large company, the enterprise architects focus on ERP processes, logistic flows, how prices flow from the system where they are managed to the places that need them, and so on. They are several levels removed from devops teams. DevOps concerns are maybe handled by tech leads, system architects or technical product managers.
Post reply on HN