HACKER Q&A
📣 jiehong

Avoid/Prove CI works in a PR without running it?


When developing in a repository, it's common to have jobs like Github's Actions triggered to check everything in the PR (build, tests, coverage, etc.).

Teams often try to speed up that process. Yet, the developer usually run some of that locally, and the job runs those steps again when the PR is created.

I am wondering if there could be a way to _prove_ that you've run a series of step locally so that the CI job can bypass those steps?

I thought that maybe a cryptographic string could be generated only by running a build, commit this, and this string could be verified without having to run the build again (easy to check, hard to generate).

(maybe something like a private key + commit hash + signature generated only by running the build, and the server checks the signature validity. Or maybe something from the blockchain?)


  👤 verdverm Accepted Answer ✓
You'll probably find https://www.sigstore.dev/ interesting

You cannot trust developer machine consistency or integrity, like never trusting user input in an app. Best to have a controlled build environment. CI is cheap all things considered, much cheaper than a supply chain exploit

I've been using Dagger more, and there is the potential to share the cache between developer machines and CI, which in theory would address your "remove duplication of work" idea, while also supporting Sigstore features.


👤 re-thc
I rather not trust any local runs even if they're valid. It's likely not the same infrastructure, configuration etc. The CI run could catch things otherwise.

Lots of local environments also cache certain things or have things preconfigured.

Yes, it's best to speed up the process rather than skipping it.

Unless we're in the C/C++/Rust/etc space, the whole process should be relatively quick. Otherwise something else is wrong.


👤 viraptor
I think you're looking at the wrong side of the issue. If you're working in a team, why would the developers ever be so hostile that you need cryptography to validate this information? Why isn't running "set($commit:tested, true)" on some shared database enough?

On the other hand, you're missing half the benefits of the CI by not ensuring the tests run in a common, predictable environment. The tests may pass for the developer but not elsewhere by accident.