161–170 of 347 posts
Earlier quoted context omitted.
1. Just no. Unless you are some sort of Windows shop.
If you're building for Windows, then bash is "just no", so it's either cmd/.bat, or pwsh/.ps.
Earlier quoted context omitted.
> It introduces more dependencies(Python which I solved via Nix) but others haven't solved this problem and the Python script has dependencies(such as Click for the CLI). UV scripts are great for this type of workflow There are even scripts which will install uv in the same file effectively making it just equivalent to ./run-file.py and it would handle all the dependency management the python version management and e…
This thing does a global uv install when run? That's obnoxious! Never running stuff from whoever wrote this. Oh, and later the author suggests the script modify itself after running. What the fuck. Absolutely unacceptable way to deploy software.
Also if this still bothers you, nothing stops you from removing the first x lines of code and having it in another .py file if this feels obnoxious to you
> Oh, and later the author suggests the script modify itself after running. What the fuck. Absolutely unacceptable way to deploy software.
Regarding author suggest its removes itself its because it does still feel clutterish but there is virtually 0 overhead in using/having it still be if you are already using uv or want to use uv
Oh also, (I am not the Author) but I have played extensively with UV and I feel like the script can definitely be changed to install it locally rather than globally.
They themselves mention it as #overkill on their website but even then it is better than whatever github action is
Earlier quoted context omitted.
That's literally point #2, but I had the same reaction as you when I first read point #1 :)
I agree with #2, I meant more if you are calling out to something that is not a task runner(Make, Taskfile, Just etc) or a shell script thats a bit of a smell to me. E.g. I have seen people call out to Python scripts etc and it concerns me.
Issue is, op is trying to use matrix strategy when with cross-compiling they could avoid it. I have done it for https://github.com/anttiharju/compare-changes (which has nontrivial CI pipelines but they could be a lot simpler for op's needs) Main issue is Rust. Writing catchy headlines about hating something may feel good, but a lot of people could avoid these pains if - zig cc gets support for new linker flag that Ru…
Ah a classic stack overflow flavored answer ala: do it differently so you don't encounter these issues
Earlier quoted context omitted.
Huh? Who cares if the script is .sh, .bash, Makefile, Justfile, .py, .js or even .php? If it works it works, as long as you can run it locally, it'll be good enough, and sometimes it's an even better idea to keep it in the same language the rest of the project is. It all depends and what language a script is made in shouldn't be considered a "smell".
> Huh? Who cares if the script is .sh, .bash, Makefile, Justfile, .py, .js or even .php? Me, typically I have found it to be a sign of over-engineering and found no benefits over just using shell script/task runner, as all it should be is plumbing that should be simple enough that a task runner can handle it. > If it works it works, as long as you can run it locally, it'll be good enough, Maybe when it is your own pe…
The other problem with shell scripting on things like GHA is that it’s really easy to introduce security vulnerabilities by e.g forgetting to quote your variables and letting an uncontrolled input through.
There’s no middle ground between bash and python and a lot of functionality lives in that space.
I've seen this over and over again over the years in projects where things like ant, maven, gradle, puppet, ansible, etc. Invariably somebody tries to do something really complicated/clever in a convoluted way. They'll add plugins, more plugins, all sorts of complex configuration, etc. Your script complexity explodes. And then it doesn't work and you spend hours/days trying to make it do the right thing and fighting a tool that just wasn't designed to do what you are doing well. The problem is using the wrong tool for the job. All these tools have the tendency to evolve into everything tools. And they just aren't good at everything. Just because it has some feature doesn't mean it's a good idea to use it.
The author actually calls this out. Just write a bash script and run that instead. If that gets too complicated pick something else more appropriate to the job. Python, whatever you like. The point here is to pick something that's easy for you to run, test, and debug locally. Obviously people have different preferences here. If you are shoe horning complex fork/join behavior, conditional logic, etc. into a Yaml / CI build, maybe simplify your build. Yaml just isn't suitable as a general purpose programming language.
Externalizing the complex stuff to some script also has the benefit of that stuff still working if you ever decide to switch CI provider. Maybe you want to move to Gitlab. Or somebody decides Jenkins wasn't so bad after all. The same scripts will probably be easy to adapt to those.
One of my current github actions basically starts a vm, runs a build.sh script, stops the vm. I don't need a custom runner for that. I get to pick the vm type. I can do whatever I need to in my build.sh. I have one project with an actual matrix build. But that's about the most complex thing I do with github actions. A lot of my build steps are just inline shell commands.
And obligatory AI comment here, if you are doing all this manually, having scripts that run locally also means you can put claude code/codex/whatever to work fixing them for you. I've been working on some ansible scripts with codex today. Works great. It produces better ansible scripts than me. These tools work better if they can test/run what they are working on.
Earlier quoted context omitted.
> i.e. the lack of a tight feedback loop. Lefthook helps a lot https://anttiharju.dev/a/1#pre-commit-hooks-are-useful Thing is that people are not willing to invest in it due to bad experiences with various git hooks, but there are ways to have it be excellent
Yeah, I'm one of those people who seems to consistently have middling-to-bad experiences with Git hooks (and Git hook managers). I think the bigger issue is that even with consistent developer tooling between both developer machines and CI, you still have the issue where CI needs to do a lot more stuff that local machines just can't/won't do (like matrix builds). Those things are fundamentally remote and kind of anno…
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.
Earlier quoted context omitted.
> Yeah, tends to happen a lot when you hold strong opinions with strong conviction :) Not that it's wrong or anything, but it's highly subjective in the end. Strong opinions, loosely held :) > Typically I see larger issues being created from "under-engineering" and just rushing with the first idea people can think of when they implement things, rather than "over-engineering" Funnily enough running with the first idea…
> It introduces more dependencies(Python which I solved via Nix) but others haven't solved this problem and the Python script has dependencies(such as Click for the CLI). UV scripts are great for this type of workflow There are even scripts which will install uv in the same file effectively making it just equivalent to ./run-file.py and it would handle all the dependency management the python version management and e…
So previously when I have seen Python used as a task runner I think they used UV to call it. Although I don't think they had as a complete solution as your here auto-installing UV etc.
Although the example you've linked is installing UV if missing, the version is not pinned, I also don't think it is handling missing Python which is not pinned even if installed locally. So you could get different versions on CI vs locally.
While yes you are removing some of the dependencies problems created via using Python over Make/Shell I don't think this completely solves it.
> Something like this can start out simple and can scale much more than the limitations of bash which can be abundant at times
I personally haven't witnessed anytime I would consider the scales to have tipped in favour of Python and I would be concerned if they ever do, as really the task runner etc should be plumbing, so it should be simple.
> That being said, I still make some shell scripts because executing other applications is first class support in bash but not so much in python but after discovering this I might create some new scripts with python with automated uv because I end up installing uv on many devices anyway (because uv's really good for python)
Using Python/UV to do anything more complex than my example PR above?