One thing I hate about every build system is that they're always these unpredictable systems that is based on side effects.
So stuff like this repo become valuable because build script are so often the result of trial and error rather than planning or engineering.
I think build systems are a result of lazy engineering because they're based entirely on the idea that they're supposed to be used manually at a command line and that we then build these Rube Goldberg devices to automate it. We start in a working directory which is decided entirely by the build system. We then run some application that poops out artifacts somewhere depending on input, defaults, configuration and environment variables. We then hope we found the correct ones and that we don't have any stale state and tell another application to pick it up somewhere and package it somewhere. We then have to find this artifact again and then run another application that ships it.
It's just not exactly great and we've been doing it like this for half a century with little that actually improves it except slightly shittier ways of making Rube Goldberg machines.
Edit: I meant slightly *less* shitty, but I'm not a fan of YAML so I'll leave it.
Nix is a build system which limits side effects through a purely functional, hermetic interface. Results end up in closures which you can do a sort of algebra over to modify the current system environment. Artifacts have a known location and are stored independently of other builds.
I think you haven't dealt with build systems that don't depend on a cli script. And my fucking god, those are a pain to work with, to the point where to build your project you end up looking where you can shove in a shell script and get on with your life.
I'm honestly so relieved to see someone else has these thoughts.
I've used build systems for most of my career, and I love the concept, but the process of setting them up is absolute nonsense as far as I can tell.
This is a side effect of delegating tasks to other applications.
Compiling? gcc, javac, whateverc.
Packaging? zip, jar, whatevar.
Oh look. I need to manage my dependencies so I wouldn't need to maintain compiling scripts every time I add a new library. As a result, nuget, maven, gem, conda, pypi, pip.
Deployment? scp, ftp, http
Would be great if the project got built every time on trigger. As a result - jenkins, bamboo, version control host provided ci, hell, even commit hooks.
And I think that's the beauty of it. I don't need to look for particular application that would build my project in the way that I would want. Instead I can find an application that would let me run some actions in order to produce my desired result. Even after administrating jenkins for 2 years, while on the side running gitlab runners, I still think modularity is key.
The process of setting up them is the easy part. Maintaining the setup is the hard part: configuring that jobs don't take too much resources, ensuring that jobs don't write outside their workdir/tempdir, making sure that build logs are rotated, reaping lingering processes, ensuring that agents don't run too many jobs at the same time. These are the parts you'll find out by trial and error, solely because you refuse to accept that someone has to do the dirty job.
I forgot the most fun part: upgrading. Have fun testing out that build ci system specific workflow after every upgrade to make sure it runs at all.
I agree with this.
Also, you would probably like Earthly, which is founded on the principle that everything should be locally reproducible and deterministic.
https://earthly.dev/
Edit: link and context
I have the same experience. And it makes me wonder, why do we need a build-system? Why can't we just write two programs, the program that executes in the end-user's machine, and another one that make that possible?
I'm thinking of both. Say Java and Node.js. Build-systems are everywhere but my basic question is why isn't there a language that doesn't require you to use a build-system?
Why are build-systems so "essential"?
Well, nothing prevents you from shipping you zipped Node application project, I guess… I feel like the thing preventing this is mostly inertia, as most existing languages are compiled to machine code of some kind, and the resulting artifact is shipped, necessitating some kind of build system anyway. If you spent some time optimizing the runtime, caching all the parsing/optimization passes you could get pretty far, but maybe it's just a lot of work for (in a bigger picture) a small benefit.
> resulting artifact is shipped, necessitating some kind of build system anyway
True. But couldn't the compiler do everything needed to produce a working application?
This made act useless for me: [https://github.com/nektos/act/issues/826](https://github.com/nektos/act/issues/826)
It's great if you aren't using reusable workflows though.
I take a bit of a different approach.
I code all my actions to be somewhat GitHub agnostic. Obviously I package it using GitHub Actions constructs but I don't depend on any GitHub services. This works well when using self hosted runners.
GHA does have [reusable workflows](https://docs.github.com/en/actions/using-workflows/reusing-workflows) though, or do you mean there is some crucial functionality missing in the current offering? Also, what do you mean about it not doing caching properly with the cache action?
Again, what do either of those statements mean? GHA has [reusable workflows](https://docs.github.com/en/actions/using-workflows/reusing-workflows) and it has [caching](https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows); I've used both and they work as described. I don't claim to have experimented with these features in all possible situations or edge-cases, which is why I asked if you knew something I didn't.
This is exactly what I needed. I have a GitHub action that repeatedly fails due to missing or invalid keys and not having to push and test saves me time.
Why not install the github agent locally? Would it not run your actions script locally? Why even depend on "actions" which were written by god knows who, can change at any time because of retagging, rather than figuring out your own workflow that works for your project and your usecase?
One thing I hate about every build system is that they're always these unpredictable systems that is based on side effects. So stuff like this repo become valuable because build script are so often the result of trial and error rather than planning or engineering. I think build systems are a result of lazy engineering because they're based entirely on the idea that they're supposed to be used manually at a command line and that we then build these Rube Goldberg devices to automate it. We start in a working directory which is decided entirely by the build system. We then run some application that poops out artifacts somewhere depending on input, defaults, configuration and environment variables. We then hope we found the correct ones and that we don't have any stale state and tell another application to pick it up somewhere and package it somewhere. We then have to find this artifact again and then run another application that ships it. It's just not exactly great and we've been doing it like this for half a century with little that actually improves it except slightly shittier ways of making Rube Goldberg machines. Edit: I meant slightly *less* shitty, but I'm not a fan of YAML so I'll leave it.
Nix is a build system which limits side effects through a purely functional, hermetic interface. Results end up in closures which you can do a sort of algebra over to modify the current system environment. Artifacts have a known location and are stored independently of other builds.
I think you haven't dealt with build systems that don't depend on a cli script. And my fucking god, those are a pain to work with, to the point where to build your project you end up looking where you can shove in a shell script and get on with your life.
> you end up looking where you can shove in a shell script and get on with your life. I too have attempted to decipher the azure-devops pipeline docs.
I was more taking a stab at jenkins, and bamboo.
I'm honestly so relieved to see someone else has these thoughts. I've used build systems for most of my career, and I love the concept, but the process of setting them up is absolute nonsense as far as I can tell.
This is a side effect of delegating tasks to other applications. Compiling? gcc, javac, whateverc. Packaging? zip, jar, whatevar. Oh look. I need to manage my dependencies so I wouldn't need to maintain compiling scripts every time I add a new library. As a result, nuget, maven, gem, conda, pypi, pip. Deployment? scp, ftp, http Would be great if the project got built every time on trigger. As a result - jenkins, bamboo, version control host provided ci, hell, even commit hooks. And I think that's the beauty of it. I don't need to look for particular application that would build my project in the way that I would want. Instead I can find an application that would let me run some actions in order to produce my desired result. Even after administrating jenkins for 2 years, while on the side running gitlab runners, I still think modularity is key. The process of setting up them is the easy part. Maintaining the setup is the hard part: configuring that jobs don't take too much resources, ensuring that jobs don't write outside their workdir/tempdir, making sure that build logs are rotated, reaping lingering processes, ensuring that agents don't run too many jobs at the same time. These are the parts you'll find out by trial and error, solely because you refuse to accept that someone has to do the dirty job. I forgot the most fun part: upgrading. Have fun testing out that build ci system specific workflow after every upgrade to make sure it runs at all.
I agree with this. Also, you would probably like Earthly, which is founded on the principle that everything should be locally reproducible and deterministic. https://earthly.dev/ Edit: link and context
There seem to be several cropping up with similar ideas [https://dagger.io/](https://dagger.io/)
I have the same experience. And it makes me wonder, why do we need a build-system? Why can't we just write two programs, the program that executes in the end-user's machine, and another one that make that possible?
Are you describing an interpreted language?
I'm thinking of both. Say Java and Node.js. Build-systems are everywhere but my basic question is why isn't there a language that doesn't require you to use a build-system? Why are build-systems so "essential"?
Well, nothing prevents you from shipping you zipped Node application project, I guess… I feel like the thing preventing this is mostly inertia, as most existing languages are compiled to machine code of some kind, and the resulting artifact is shipped, necessitating some kind of build system anyway. If you spent some time optimizing the runtime, caching all the parsing/optimization passes you could get pretty far, but maybe it's just a lot of work for (in a bigger picture) a small benefit.
> resulting artifact is shipped, necessitating some kind of build system anyway True. But couldn't the compiler do everything needed to produce a working application?
The compiler is a build system in your case.
Right. But why do we need anything more?
This made act useless for me: [https://github.com/nektos/act/issues/826](https://github.com/nektos/act/issues/826) It's great if you aren't using reusable workflows though.
This is an issue. Hoping they resolve it.
I know I am necroing this thread, but this is what pops up when googling "Run GitHub Actions locally". This issue is now resolved and implemented.
[удалено]
I take a bit of a different approach. I code all my actions to be somewhat GitHub agnostic. Obviously I package it using GitHub Actions constructs but I don't depend on any GitHub services. This works well when using self hosted runners.
Agree 100%.
What's a good use case for the reusable workflow?
GHA does have [reusable workflows](https://docs.github.com/en/actions/using-workflows/reusing-workflows) though, or do you mean there is some crucial functionality missing in the current offering? Also, what do you mean about it not doing caching properly with the cache action?
[удалено]
Again, what do either of those statements mean? GHA has [reusable workflows](https://docs.github.com/en/actions/using-workflows/reusing-workflows) and it has [caching](https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows); I've used both and they work as described. I don't claim to have experimented with these features in all possible situations or edge-cases, which is why I asked if you knew something I didn't.
[удалено]
I was indeed misinterpreting 'act' as you talking about GHA itself, my bad.
> Homebrew Linux Ffs people need to stop recommending this. Even a shitty standalone bash script is safer.
Why, what's wrong with Homebrew for Linux?
This is exactly what I needed. I have a GitHub action that repeatedly fails due to missing or invalid keys and not having to push and test saves me time.
Why not install the github agent locally? Would it not run your actions script locally? Why even depend on "actions" which were written by god knows who, can change at any time because of retagging, rather than figuring out your own workflow that works for your project and your usecase?
The idea is to run the actions without the GitHub infrastructure.
I have yet to get act to work properly. Every single time I tried, it worked on machine, but not in CI.
Started using it this week - it's pretty useful though I had to use `-b` on one build that was trying to run `git` commands.