331–340 of 347 posts
Earlier quoted context omitted.
I'm scared by all these references to nix in the replies here. Sounds like I'm going to have learn nix. Sounds hard.
Gemini/ChatGPT help (a lot) when getting going. They make up for the poor documentation
Earlier quoted context omitted.
> However it’s really easy to go from a simple shell script running a few commands to something significantly more complex just to do something seemingly simple, like parse a semantic version, make an api call and check the status code etc, etc. Maybe I keep making the wrong assumption that everyone is using the same tools the same way and thats why my opinions seem very strong. But I wouldn't even think of trying to…
Let’s say have a folder of tarballs and need to install the latest version. I could reach for an additional “dedicated” tool, get it installed into the CI environment and then incorporate it into the build process, or I could just make a slight modification to my existing shell script and do something like “ls mypkg-*.tar.gz | xargs -n1 | sort -Vr | head -n1” and then move on. But then we start publishing multiple re…
I know it is a made up example, but I am not sure Python would improve the situation. I would be looking at either Docker or SBOMs to try and improve the situation and then hopefully the release process would become a lot simpler.
Its not Github Actions' fault but the horrors people create in it, all under the pretense that automation is simply about wrapping a GitHub Action around something. Learn to create a script in Python or similar and put all logic there so you can execute it locally and can port it to the next CI system when a new CTO arrives.
Earlier quoted context omitted.
"pwsh" is often used as the short-hand for modern cross-platform PowerShell to better differentiate it from the old Windows-only PowerShell. I think pwsh is worth exploring. It is cross-platform. It is post-Python and the Python mantra that "~~code~~ scripts are read more often than they are written". It provides a lot of nice tools out of the box. It's built in an "object-oriented" way, resembling Python and owing m…
It's also both a larger download and slower to start than Java, which is not known for being light and nimble. In fact, PowerShell is so slow that you can both compile and run the equivalent C# program before PowerShell finishes launching. Not ideal for a shell or a scripting language. Also, the newer versions aren't included with Windows, which would have been useful – instead Windows includes an incompatible older…
The new versions aren't included in Windows and the old versions are still in Windows for the exact same reasons of Windows backwards compatibility requirements. But at this point the bootstrap on Windows is as easy as `winget install --id Microsoft.PowerShell`.
The error handling isn't far from the bash defaults, but the magic incantations actually tell you what they do versus the number of bash scripts littered with `set -euxo pipefail` is the exact same as the number of scripts that need an `$ErrorActionPreference = "Stop"` and/or a `$PSNativeCommandUseErrorActionPreference = true`.
I find the documentation less vague and more useful than the average `man` page and the syntax is fine (and better than bash) to me, but I understand how much of that is personal preference and familiarity.
Earlier quoted context omitted.
Not sure what you mean by "smallest". With GitLab you create docker images. That means you can easily run them locally and share them. In the example you gave the GitHub actions one looks like more lines of YAML but only works because they made an "action". If they had provided a Docker image then GitLab would be just as easy (and trivial to test locally).
mise already is trivial to test locally though, and I'm not sure I agree that maintaining a CI config + Docker image is just as easy as maintaining a CI config.
Again, I don't mine gitlab ci, but they have no solution for sharing repeated tasks.
This is why I started DSCI - https://github.com/melezhik/DSCI
One can replace GitHub actions yaml pipeline runner by general purpose languages/scripts but still using all other standard features of GitHub server
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
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. CI is RCE-as-a-service, you implicitly give permission for anyone who can edit build scripts to run arbitrary code. Like you say, they can echo the secret to a file & upload it elsewhere, and they can also use it directly from the edited build script.
Earlier quoted context omitted.
I think you described Jenkins, which is infinitely better than GitHub runners.
Jenkins has it's own set of issues. The theory behind GHA is you *should* be able to keep everything in git and not need a another service with it's own abstractions. But Actions just screws this up. I consider them both to be equally bad. I'm almost considering n8n to replace both but that will just lead to more problems.
Clone
Cd $clonedFolder
./build.sh
Add an archive step, all set.
I will say even building and running unit testing in Jenkins isn’t bad, but if you aren’t careful it can get messy.
Jenkins can be a super simple build tool. Strong-arming it into doing all the things starts to get messy quickly. Build, run unit tests, archive. I’m not even big on like, building on push. Nothing wrong with it, I’m just big on keeping things as simple as possible. GHA is just a ball of complexity.
1. Don't use bash, use a scripting language that is more CI friendly. I strongly prefer pwsh. 2. Don't have logic in your workflows. Workflows should be dumb and simple (KISS) and they should call your scripts. 3. Having standalone scripts will allow you to develop/modify and test locally without having to get caught in a loop of hell. 4. Design your entire CI pipeline for easier debugging, put that print state in, e…
I was once hired to manage a build farm. All of the build jobs were huge pipelines of Jenkins plugins that did various things in various orders. It was a freaking nightmare. Never again. Since then, every CI setup I’ve touched is a wrapper around “make build” or similar, with all the smarts living in Git next to the code it was building. I’ll die on this hill.