321–330 of 347 posts
Earlier quoted context omitted.
https://github.com/nektos/act Lets you run your actions locally. I've had significant success with it for fast local feedback.
I tried this five years ago back when I was an engineer on the PyTorch project, and it didn't work well enough to be worth it. Has it improved since then?
Earlier quoted context omitted.
I’ve contemplated building my own CI tool (with a local runner) and the thing is if you assume “write a pipeline that runs locally but also on push”, then the feature depth is mostly about queuing, analyzing output, and often left off, but IMO important, charting telemetry about the build history. Most of these are off the shelf, at least in some programming languages. It’s the integrations and the overmanagement whe…
I think you described Jenkins, which is infinitely better than GitHub runners.
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.
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.
The hard parts are things like deploying artifacts, publishing releases, caching, etc. that are CI-specific and can't be run locally.
All discussions so far seem to be around building artifacts which is the easy part. How to make the full CI/CD pipeline work with GHA is a pain. GHA has no state mechanism easily used, you have to create it all yourself.
Earlier quoted context omitted.
> If your CI can do things that you can't do locally: that is a problem. IME this is where all the issues lie. Our CI pipeline can push to a remote container registry, but we can't do this locally. CI uses wildly different caching strategies to local builds, which diverges. Breaking up builds into different steps means that you need to "stash" the output of stages somewhere. If all your CI does is `make test && make…
Ironically, at least for a couple recent projects... just installing dependencies fresh is as fast on GH Actions as the GH caching methods, so I removed the caching and simplified the workflows.
> i.e. a way that I could testbed different runs without polluting history of both Git and Action runs. How about writing a separate repo and testing it separately Keywords: reusable workflow/actions
> For the love of all that is holy, don’t let GitHub Actions > manage your logic. Keep your scripts under your own damn > control and just make the Actions call them! The pain is real. I think everyone that's ever used GitHub actions has come to this conclusion. An ideal action has 2 steps: (1) check out the code, (2) invoke a sane script that you can test locally. Honestly, I wonder if a better workflow definition w…
How do you orchrestate a full CI/CD pipeline where you need state? You just move that complex logic to another monolithic script with its own problems?
Earlier quoted context omitted.
Ah, magnificent! Thanks!
Sure thing. Also just made it easier to install with Homebrew since people seem to be liking it.
Earlier quoted context omitted.
I found gitlab ci's yaml the smallest of the 3 I've used (gitlab, GitHub actions, CircleCI). But does gitlab ci have anything for sharing? GitHub actions are built around it, and CircleCI has orbs and contexts. For example, muse's guide for gitlab involves making your own container and managing the cache yourself (ref: https://mise.jdx.dev/continuous-integration.html#gitlab-ci ) GitHub actions is a couple of lines (r…
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).
Earlier quoted context omitted.
I use to have my Makefile call out and do `docker build ...` and `docker run ...` etc with a volume mount of the source code to manage and maintain tooling versions etc. It works okay, better than a lot of other workflows I have seen. But it is a bit slow, a bit cumbersome(for langs like Go or Node.js that want to write to HOME) and I had some issues on my ARM Macbook about no ARM images etc. I would recommend taking…
You mean nix inside a container? Or what exactly?
* https://github.com/DeveloperC286/clean_git_history/commit/f8...