4 ms·
This piece of software would have to handle all the intricacies of the GitHub actions but also be updated to the latest changes... We are moving back to a make
by ta988 4y ago
This piece of software would have to handle all the intricacies of the GitHub actions but also be updated to the latest changes...
We are moving back to a makefile based approach that is called by the GitHub workflows. We can handle different levels of parallelism: the make kind or the indexed by worker number when running in actions. That way we can test things locally, we can still have 32 workers on GitHub to run the full suite fast enough.
I also like that we are less bound to GitHub now because it has been notorious unreliable for us this past year and we may move more easily to something else.
- counttheforks 4y agoIs this public?
- ta988 4y agoNo, sorry about that.
- Xelynega 4y agoYou could implement something similar by splitting the make targets in the GitHub action before they get passed to make so each worker is assigned their own target, then have a make target that executes all the targets for local multithreaded builds via `make -j${NUM_CONCURRENT}`.
- killingtime74 4y agohttps://batect.dev/ https://batect.dev/ this is like Act but agnostic and public
- mdaniel 4y agoAre you sure you mean "like Act?" https://batect.dev/docs/using-batect-with/ci/github-actions https://batect.dev/docs/using-batect-with/ci/github-actions seems to imply it is its own build system, closer to Dagger or Earthly, but not a GitHub Actions "emulator" as act is trying to be
- tonyhb 4y agoTake a look at https://dagger.io/ https://dagger.io/. Declarative pipelines using Node, Python, or Go. Parallelism built in, and caching built in - things are cached if they're unchanged.
- stepbeek 4y agoYes! We use gradle as much as possible to accomplish the same thing. CI runs ‘gradle build’ and it’s easily migrated in future if need be.
- wkdneidbwf 4y agoi do the same, but with Task