Add support for running Linux-based actions workflows locally using nektos/act - #6296
Open
bernhardkaindl wants to merge 1 commit into
Open
Conversation
bernhardkaindl
requested review from
alalazo,
alecbcs,
haampie and
kwryankrattiger
as code owners
September 1, 2026 00:53
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hi, I think this PR needs a small introduction:
The
acttool (github.com/nektos/act) is an established Go tool which developers can use to run jobs defined in GitHub Actions locally in Linux-based docker or podman containers.Because it uses docker, it uses regular docker images, not the special Linux distrubution images used by GitHub and as it does not run inside a real GitHub push or PR workflow event, there are some differences.
With a few tweaks to the workflows,
actcan a number of worflows in these docker containers.The idea behind this PR is that, for example, also with some nice user interfaces (see belwo), it can be interesting to be able to run spack's GitHub workflow-defined CI jobs locally before pushing to GitHub to utilize local feedback loops for development.
A further motivation for supporing this path can be to support users to contain their code execution in
dockerorpodmancontainers, so the code can't access or modify user's files outside of the spack-packages repo (when using or configuring act --bind, the source repo would be bind-mounted, in this case it would be able to modifiy the source repo, but without--bindconfigured, the job only gets a copy of the source repo and any changes it would make are local to the container and ephermeral)Possibly other ways to implement support for using act can be found (e.g. configuring it to not simulate the GitHub push event for the jobs), so please see this as proposal for consideration in general, not as the only way this can be done.
PS: The Act Visual Runner (A MIT-licensed VS Code extension by a brazilian Web developer, he also merged my 15 PRs, including one that enables it to use English/Brazilian localisation strings - the last release was only using Brazilian Portuguese translations unconditionally, the next release will be bilinugal - to be done) is very nice graphical frontend for
actthat even provides some interfaces GitHub doesn't even provide: