[
https://issues.apache.org/jira/browse/DAFFODIL-2971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Lawrence resolved DAFFODIL-2971.
--------------------------------------
Fix Version/s: 4.0.0
Resolution: Fixed
All above steps have been completed. Future releases should be able to use this
new workflow. Marking as fixed.
> Setup release candidate workflow using github tags
> --------------------------------------------------
>
> Key: DAFFODIL-2971
> URL: https://issues.apache.org/jira/browse/DAFFODIL-2971
> Project: Daffodil
> Issue Type: Improvement
> Components: Infrastructure
> Reporter: Steve Lawrence
> Priority: Major
> Fix For: 4.0.0
>
>
> Although the release candidate workflow is somewhat automated via the
> release-candidate-container, it is still sometimes difficult to just get the
> container up and running. ASF Infra allows automated build CI to do release
> candidates (a signing key and passwords are added as CI secrets), but it
> requires reproducible builds and that part of the release candidate process
> verifies release candidate reproducibility.
> Although it's not a small amount of work, once complete it would 1) ensure
> builds are reproducible, which we should do anyways, and 2) make it so the
> only step to creating a release candidate is pushing a single tag and sending
> out a release vote--significantly less work than setting up and running a
> container.
> These are the things that need to be done to enable this:
> 1. Modify all our repos to have reproducible builds. VS Code and Daffodil
> have a couple outstanding issues, but should be easy to resolve or already
> have PR's to fix them. SBT Plugin is already reproducible
> 2. Create a new container that is similar to the current release-candidate
> container, but removes all the complexity related to publishing. Instead it
> just creates all the artifacts that would normally be published and makes
> them available for reproducibility checks.
> 3. Create a script that downloads release candidate artifacts and compares
> them against the artifacts created by the container.
> 4. Create a wiki page that documents the steps required to verify release
> candidate reproducibility using the new container and script from steps 2 and
> 3. The steps described in this page must be done during release candidate
> voting to verify that release candidates are reproducible. Note that not
> every single voter must do this, but the more the better.
> 5. Add a new github action that creates and publishes release candidates when
> a tag is created. This will use secrets configured by INFRA, and should
> perform similar actions in a similar environment as the new container so that
> reproducible builds can be verified.
> 6. Once this is all done, we can remove the release-candidate-container.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
