Repository navigation
Establish a CI system to enable reproducible, verifiable releases/artifacts #1871
Description
Artifact releases need to be reproducible, verifiable, and automated. A robust CI/CD for release should consider:
- Dependency and asset tracking
- Code and artifact signing and verification (provenance)
- Artifact publication and consumption
- Guardrails (testing and contract validation)
Proposal: Agent Substrate Release Pipeline.
Activity
BenTheElder commentedon Sep 25, 2026
Reproducible builds are pretty easy for Go these days but we're probably going to have some other artifacts that are not so easy, microVM assets (maybe a secondary repo), and the rust bits.
I think reproducible is a nice to have, secure community pipeline is more important
stshrive commentedon Sep 25, 2026
I think you're right about the Golang context. That being said, the big ticket items are more like code and artifact signing decisions, and getting SBOMs for verification. I added the proposal to the issue for review.
CI: create JUnit artifacts and gate on all tests passing (agent-subst…
ci: automate release artifact build and publish (agent-substrate#2112)
MushuEE commentedon Oct 26, 2026
I was looking closer at #2112, IIUC GHCR sets the visibility at the package level. So after the first version cut with the new CI is marked public, all future cuts will become publish as soon as they are uploaded. Double checking that is WAI. Unsure if we wanted to gate public image publishing until there was a chance to validate against e2e etc.
BenTheElder commentedon Oct 26, 2026
Or until the actual release is published?