starred/act

Fork 0

mirror of https://github.com/nektos/act.git synced 2026-04-26 01:15:51 +03:00

[GH-ISSUE #235] Feature Request: GPG-signing of test results #161

New issue

Closed

opened 2026-03-01 21:40:45 +03:00 by kerem · 3 comments

kerem commented

2026-03-01 21:40:45 +03:00

Owner

Originally created by @jayaddison on GitHub (May 13, 2020).
Original GitHub issue: https://github.com/nektos/act/issues/235

User story
As a developer, I'd like to make frequent commits, and would like to run my tests via act so that I can receive test feedback before GitHub actions run after a push.

Additionally, as a considerate user of costly infrastructure, I would prefer to minimize the amount of compute resources used by GitHub actions and/or any other CI providers linked to the project(s) I work on.

I would like the ability to GPG-sign my commits to indicate a pass/fail test result 'on my machine', so that these claimed test results are visible to other viewers of my commits and pull requests.

Caveats
A GPG-signed pass or failure would would not be a cast-iron guarantee of a replicable result.

Trust in the developer is required - it would be possible for a developer to accidentally or maliciously corrupt their commit pass/fail results; but it is likely the case that developers are incentivized to illustrate that they are reliable, careful and trustworthy -- and that should strongly encourage accurate test result signing
Not all languages and environments are perfectly reproducible - a commit that genuinely did pass for a developer locally may fail in other build environments, for a variety of reasons (different operating system behaviours, presence/lack of secrets, different dependencies retrieved at build-time, bugs relating to concurrency, ...)
It would require upstream support from GitHub and/or CI providers to allow 'skipping' invocation of cloud-based compute actions based on a GPG-signed commits
Some developer configuration would be required, and dealing with GPG keys can be challenging. This is not necessarily act's problem to solve, but it would be a factor in adoption

Originally created by @jayaddison on GitHub (May 13, 2020). Original GitHub issue: https://github.com/nektos/act/issues/235 **User story** As a developer, I'd like to make frequent commits, and would like to run my tests via `act` so that I can receive test feedback before GitHub actions run after a push. Additionally, as a considerate user of costly infrastructure, I would prefer to minimize the amount of compute resources used by GitHub actions and/or any other CI providers linked to the project(s) I work on. I would like the ability to GPG-sign my commits to indicate a pass/fail test result 'on my machine', so that these claimed test results are visible to other viewers of my commits and pull requests. **Caveats** A GPG-signed pass or failure would would not be a cast-iron guarantee of a replicable result. - Trust in the developer is required - it would be possible for a developer to accidentally or maliciously corrupt their commit pass/fail results; but it is likely the case that developers are incentivized to illustrate that they are reliable, careful and trustworthy -- and that should strongly encourage accurate test result signing - Not all languages and environments are perfectly reproducible - a commit that genuinely did pass for a developer locally may fail in other build environments, for a variety of reasons (different operating system behaviours, presence/lack of secrets, different dependencies retrieved at build-time, bugs relating to concurrency, ...) - It would require upstream support from GitHub and/or CI providers to allow 'skipping' invocation of cloud-based compute actions based on a GPG-signed commits - Some developer configuration would be required, and dealing with GPG keys can be challenging. This is not necessarily `act`'s problem to solve, but it would be a factor in adoption

kerem

2026-03-01 21:40:45 +03:00

closed this issue
added the
kind/feature-request

stale
labels

kerem commented

2026-03-01 21:40:46 +03:00

Author

Owner

@cplee commented on GitHub (May 14, 2020):

@jayaddison - seems interesting, but not clear on what part of this workflow act will plan. You could definitely use a post-commit hook to run act, but then how does the signature get applied? Do you want act to amend the commit to add the signature? Could the post commit hook just be a bash script that runs act and then git commit --amend?

@cplee commented on GitHub (May 14, 2020): @jayaddison - seems interesting, but not clear on what part of this workflow `act` will plan. You could definitely use a post-commit hook to run `act`, but then how does the signature get applied? Do you want `act` to amend the commit to add the signature? Could the post commit hook just be a bash script that runs `act` and then `git commit --amend`?

kerem commented

2026-03-01 21:40:46 +03:00

Author

Owner

@jayaddison commented on GitHub (May 14, 2020):

@cplee Good questions.

As additional context: while it may be convenient to allow developers to automate the process via commit hooks, it may also be good to allow them to act sign (or re-sign) commits manually -- for example, if they fix their environment and then want to re-run tests before pushing their commits -- or if they only want to sign a subset of commits.

Given that extra scenario, a new flag along the lines of act --sign (and perhaps act -S as an abbreviation, since that aligns with git commit -S) might make sense.

Now we get to your core question - how does this apply. Two possible approaches spring to mind:

Add a signed tag to each commit with test result metadata
Amend the existing commit with test result metadata

Tag-signing considerations
Tags are interesting because they preserve the integrity of the existing commit SHA.

They can also be considered somewhat ephemeral (like branches), and can be added and removed over time.

'Release tags' may be considered a stricter exception, whereby developers should not really remove a tagged (and potentially signed) tag once versioned content has been available for general consumption.

Commit-signing considerations
Commits are in some senses 'easier' -- they can be amended, as you mention, and content authors generally become familiar with commits at an earlier point in their git learning curve than tags. Tags, for example, typically require an additional command-line flags to push alongside commits.

Thoughts (work-in-progress)
To ease developer experience I think I would lean towards amending and signing commits - it'd be good to discuss further though (and gather wider feedback).

PS: As an aside, I noticed that there's already a concept of an ~/.actrc, and would suggest that could be a good place for (opt-in, default disabled) signing configuration.

@jayaddison commented on GitHub (May 14, 2020): @cplee Good questions. As additional context: while it may be convenient to allow developers to automate the process via commit hooks, it may *also* be good to allow them to `act` sign (or re-sign) commits manually -- for example, if they fix their environment and then want to re-run tests before pushing their commits -- or if they only want to sign a subset of commits. Given that extra scenario, a new flag along the lines of `act --sign` (and perhaps `act -S` as an abbreviation, since that aligns with `git commit -S`) might make sense. Now we get to your core question - how does this apply. Two possible approaches spring to mind: - Add a signed tag to each commit with test result metadata - Amend the existing commit with test result metadata **Tag-signing considerations** Tags are interesting because they preserve the integrity of the existing commit SHA. They can also be considered somewhat ephemeral (like branches), and can be added and removed over time. 'Release tags' may be considered a stricter exception, whereby developers should not really remove a tagged (and potentially signed) tag once versioned content has been available for general consumption. **Commit-signing considerations** Commits are in some senses 'easier' -- they can be amended, as you mention, and content authors generally become familiar with commits at an earlier point in their git learning curve than tags. Tags, for example, typically require an additional command-line flags to push alongside commits. **Thoughts (work-in-progress)** To ease developer experience I think I would lean towards amending and signing commits - it'd be good to discuss further though (and gather wider feedback). PS: As an aside, I noticed that there's already a concept of an `~/.actrc`, and would suggest that could be a good place for (opt-in, default disabled) signing configuration.

kerem commented

2026-03-01 21:40:46 +03:00

Author

Owner

@github-actions[bot] commented on GitHub (Jul 14, 2020):

Issue is stale and will be closed in 7 days unless there is new activity

@github-actions[bot] commented on GitHub (Jul 14, 2020): Issue is stale and will be closed in 7 days unless there is new activity

kerem referenced this issue

2026-03-01 21:52:01 +03:00

[PR #828] [MERGED] fix: rewrite how image env is merged #1633

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/act#161

No description provided.

Rows
Columns