There's no excuse to complain about bad software these days. Fork Gitea, and make your own GitHub actions, it should take a day with coding agents.
I hate GitHub Actions with passion
311–320 of 347 posts
Re: I hate GitHub Actions with passion
#312Its 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.
No, it is github's fault. They encourage the horrors because they lead to vendor lock in. This is the source of most of Microsoft's real profit margins. This is probably why they invented a whole programming language and then neglected to build any debugging tools for it.
[dead]
Re: I hate GitHub Actions with passion
#313Earlier quoted context omitted.
You haven't engaged with what I wrote, of course it doesn't make sense. The easiest and most accessible way to attest what has been done is to have all the logic of what needs to be done in a single context, a single place. A reusable workflow that is executed by hash in a trusted environment and will execute exactly those steps, for example. In this case, step A does x, and step B attests that x has been done, becau…
Usually, the people writing the Makefile are the same that could also be writing this stuff out in a YAML (lol) file as the CI instructions, often located in the same repository anyway. The irony in that is striking. And then we have people who can change environment variables for the CI workflows. Usually, also developers, often the same people that can commit changes to the Makefile. I don't think it changes much,…
Not really, that's the point. Reusable workflow, in a tightly controlled repos avoid exactly what you are saying and they are a fairly standard practice (if anything, also to avoid having 200 versions of CI instructions).
You can also verify attestations provenance by enforcing attestation performed via that particular, approved workflow, which is not security theater, it's actual real controls.
Re: I hate GitHub Actions with passion
#314Earlier quoted context omitted.
Usually, the people writing the Makefile are the same that could also be writing this stuff out in a YAML (lol) file as the CI instructions, often located in the same repository anyway. The irony in that is striking. And then we have people who can change environment variables for the CI workflows. Usually, also developers, often the same people that can commit changes to the Makefile. I don't think it changes much,…
You're correct. It's absolutely security theater. Either you trust the repository contents or you don't. There's no, none, zilch trust improvement arising from the outer orchestration being done in a YAML file checked into the repo and executed by CI instead of a Makefile also executed by CI. What's the threat model Wilder is using exactly? Look, I'm ordinarily all for nuance and saying reasonable people can disagree…
See my other comment.
> when the implementation of these actions at some level live in the repo anyway
This is the false assumption. You can standardize that not to happen, and you can verify at runtime that's not the case. You can control admission of container images for example, restricting those that were built by your workflow X (the approved, central, controlled, standard one) and reject anything else. You do this via build provenance attestation.
With makefile I don't know how you can achieve standard and centrally manageable (and verifiable) instructions (which are part of SLSA).
Re: I hate GitHub Actions with passion
#315> A word of explanation. I’m building tmplr for 4 platforms: > Linux ARM > macOS ARM > Linux x86_64 > macOS x86_64 Oh, here we go again. Java was invented to solve that, "Write once run everywhere" :] I.e. `int` means `i32` on all platforms, no `usize`.
Java has numerous problems, it's not as simple as use Java not Rust. To be honest I actively avoid any tooling written in Java.
jAvA BaD!!1
Re: I hate GitHub Actions with passion
#316Earlier 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
Calling nix documentation poor is an insult to actually poor documentation.
Remember the old meme image about Vim and Emacs learning curves? Nix is both of those combined.
It's like custom made for me on the idea level, declarative everything? Sign me up!
But holy crap I have wasted so much time and messed up a few laptops completely trying to make sense of it :D
Re: I hate GitHub Actions with passion
#317> I don’t even remember hating any other piece of technology I used
Jira, Microsoft Teams, HP Printers, Ticketmaster, …
Re: I hate GitHub Actions with passion
#318Earlier quoted context omitted.
You're correct. It's absolutely security theater. Either you trust the repository contents or you don't. There's no, none, zilch trust improvement arising from the outer orchestration being done in a YAML file checked into the repo and executed by CI instead of a Makefile also executed by CI. What's the threat model Wilder is using exactly? Look, I'm ordinarily all for nuance and saying reasonable people can disagree…
See my other comment. > when the implementation of these actions at some level live in the repo anyway This is the false assumption. You can standardize that not to happen, and you can verify at runtime that's not the case. You can control admission of container images for example, restricting those that were built by your workflow X (the approved, central, controlled, standard one) and reject anything else. You do t…
Maybe a concrete example would help.
> With makefile I don't know how you can achieve standard and centrally manageable (and verifiable) instructions (which are part of SLSA).
The way I'm thinking about it, we distinguish instructions from policy. Policy, of course, has to be imposed from outside a package somehow, but the instructions taken within policy seem like things that should evolve with it. For example, "no network access" might be an externally enforced policy. Another might be limitations of dependencies, enforced by making exceptions to the previous policy.
But in the end, you have to do something. Are you suggesting a model in which a project's entire test suite lives in a separate repository with an access control policy that differs from that project's so that the project's authors can't cheat on test coverage or pass rate?
Sure, you can do that, but the instructions for running those tests still have to live somewhere, and a makefile in that test repository seems like as good a place as any.
Re: I hate GitHub Actions with passion
#319Earlier quoted context omitted.
See my other comment. > when the implementation of these actions at some level live in the repo anyway This is the false assumption. You can standardize that not to happen, and you can verify at runtime that's not the case. You can control admission of container images for example, restricting those that were built by your workflow X (the approved, central, controlled, standard one) and reject anything else. You do t…
Maybe a concrete example would help. > With makefile I don't know how you can achieve standard and centrally manageable (and verifiable) instructions (which are part of SLSA). The way I'm thinking about it, we distinguish instructions from policy. Policy, of course, has to be imposed from outside a package somehow, but the instructions taken within policy seem like things that should evolve with it. For example, "no…
A classic example would be build (container build) images instructions.
Of course, other examples are running a security static analysis, running tests, or whatever other standard practice is desidered for security.
Say that you build 100 images, each with its own repository where there is the code, there is the Dockerfile etc. Now, if you build images with "make build", it means that ultimately the actual command line flags for the build command are going to be in the Makefile, inside each repository. These flags could include flags like --cache-from, build arguments, --add-host, or many other flags that may not be desirable in an organization. Imagine what the workflow file would like for such a case: you have your in-repo CI file that clones the repo, and then executes make test, make build, make push, etc. Do you know if make push sent the PCI registry secret somewhere else on the internet? Do you know what exactly flags were used to build? Not really, you need to trust the code inside the repo to at most collect this information, and how do you know it was not tampered or spoofed?
Compare it with the following scenario: All 100 repos at some point in that CI invoke an external workflow, which contains instructions to build images, push them to the registry (and run tests before, whatever). This can obviously also be a combination or workflows, I am saying one for simplicity. This workflow (or workflows) at the end produces an attestation, including provenance data and about what is run. It can do so reliably, because the instructions of what had to be done are within its own context. There is no input that comes from outside (e.g., the repository) that determined build flags or instructions, outside of what the workflow exposed (e.g., few variables).
In the second case, I can then use a policy that restrict images that have attestation and that were built by my workflow(s) that contain standard and deterministic instructions. This way I know that no image was built using weird build flags, including strange dependencies, maybe tampering with network and DNS (in makefile I can write whatever) or local docker cache, etc. I know this because a standard workflow was executed in a fresh, "sterile" environment with a standard set of instructions, that can't be changed or tampered by those controlling the repository content.
Note that all of the above is solely concerned with being able to make security statements on the build artifact produced, not on the context of the build (e.g., no network access).
Re: I hate GitHub Actions with passion
#320I 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…
https://github.com/nektos/act Lets you run your actions locally. I've had significant success with it for fast local feedback.
I tried act, on the surface it seems like a godsend. Not until you try to use it do you realize it's almost impossible to recreate any moderately complex workflow.
You HAVE to run it against a container, so if you're using self hosted runners your environment may not match at all.