...
Build the Daffodil release candidate image:
Code Block language bash $ podman build -t daffodil-release-candidate /path/to/daffodil.git/containers/release-candidate/
This may take 20-30 minutes the first time, but should be significantly faster in subsequent runs unless something changes in the image where a full rebuild is needed.
This requires substantial free disk space. If you need to control where podman puts this storage, you can specify the --tmpdir, --root, and --runroot directories as ABSOLUTE paths. (Relative paths are known to cause issues.). Note that if you specify these additional flags on this podman build command you must also specify them for the podman run command below.
Run the daffodil release candidate container:
Code Block language bash $ podman run -itit --rm \ -v ~/.gitconfig:/root/.gitconfig \ -v ~/.gnupg/:/root/.gnupg/ \ -v ~/.ssh/:/root/.ssh/ \ --hostname daffodil.build \ daffodil-release-candidate
Note that the
-v
option is used to bind mount files/directories from the host system in the container so the container has access to git configurations and gpg/ssh keys.The
--dry-run
option can be provided to the very end of the above podman command (e.g.... daffodil-release-candidate --dry-run
) to perform a test without publishing any artifacts.The
--entrypoint /bin/bash
option can be provided before the last argument in the above podman command (e.g.... --entrypoint /bin/bash daffodil-release-candidate
) to interactively view the configuration settings and manually run the daffodil-release-candidate script. This can be useful for debugging the container or testing changes.
The container will periodically ask for user input (e.g. usernames, passwords) to sign and publish release files. This includes:
- Release candidate label. For example:
rc1
if this is the first release candidate. Note that this should not include the release version number (e.g.2.0.0-rc1
)–it should only contain thercX
part. Note that neither this nor any other prompted input has any default value. You must type in the "rc1" (or other) string.
- Long format of your signing key ID. This can be found by running
gpg --list-secret-keys --keyid-format long
. The key ID should be the 40 character one to minimize chance of collisions. Insure this is the key ID for your apache.org email for your signing key, not some other identity.
- Git name and email (e.g. "John Doe" and "john.doe@company.com"). This is the name and email you want to show up as the "Committer" when the release script creates a git tag or commit, which could potentially be different than what is the the bind mounted
.gitconfig
file. This is not your GitHub or Apache credentials--simply the name and email address you use for Daffodil commits.If you have Github's Email Privacy setting on, be sure to use the private email provided in your Github Settings, otherwise the complete-release script will fail.
- Apache username and password. This is the username and password credentials used to log in at https://id.apache.org.
- GitHub SSH key password. The Daffodil repository will be cloned using SSH authentication. If your SSH key is password protected, you may be prompted for that password.
- Private GPG password (also called the 'pass phrase'). The release process will sign artifacts with your private GPG key–you will be prompted for a password to enable it to use your private key to sign these artifacts.
- Release candidate label. For example:
After entering the necessary information, this script will perform the following actions:
- Create a zip of the source
- Create tgz, zip, msi, and rpm of the helper binary
- Create sha256 and sha512 checksum and ASCII armored detached signatures of the above files
- Place the above files to the Apache dist dev directory. This svn files are not comitted until further action is taken.
- Create javadoc and scaladoc and move to the daffodil site repository docs directory for this release, and create a commit. This commit is not pushed until further action is taken.
- Create a signed git tag. This tag is not pushed until further action is taken.
- Stage jars/poms to https://repository.apache.org
- Create a zip of the source
- Once the script completes, you should verify the existence generated files. Note The script will list the files and locations to verify. This includes:
Verify the checksums and signatures are created in the Apache dist directories and are read for commit, for example:
Code Block $ cd /root/incubator-daffodil-dist/ $ ls -R $ svn status
Verify the git tag is attached to the correct commit in the Daffodil repo, for example:
Code Block language bash $ git -C /root/incubator-daffodil/ log -n 1
Verify the javadoc and scala docs for the version to be released exist in the daffodil site repository.
This can be done with git log:
Code Block language bash $ git -C /root/incubator-daffodil-site/ log -n 1 -p
or via the file system:
Code Block $ cd /root/incubator-daffodil-site/ $ ls -R
- Verify the all the expected jars/poms at https://repository.apache.org/ exist (i.e for all modules, both scala versions exists, and for each scala version, there exists a jar, javadoc jar, sources jar, and pom, and for each of those files there exists the armored ASCII file, and the associated md5 and sha1 checksums of all of these).
To do so, visit that url, login in the top right using id.apache.org credentials, select "Staging Repositories" on the left, and find theorgapachedaffodil-XXXX
repository. Inspect the "Content"
tab to make sure the appropriate jars are uploaded and appear valid.
- If any of the above do not look correct, perform the following steps:
- Drop the published jars/poms at https://repository.apache.org--check the box for the staging repository just created and choose "Drop" at the top)
- Type
exit
to close the container. All files/commits created in the container will be deleted.
- Fix the issue and repeat the "Create Release Candidate" process from the beginning.
- Drop the published jars/poms at https://repository.apache.org--check the box for the staging repository just created and choose "Drop" at the top)
- After verifying all is correct, follow the instructions to complete the release candidate. These steps include:
Run the command:
Code Block language bash $ /root/complete-release
All the previous commands have prepared commits and tags in the three repositories (Apache Dist, Daffodil, and Site). Running this command will push those commits and tag to the remote repositories.
- Close the staged file at https://repository.apache.org
- Type
exit
to close the container.
...
- Find all tickets that have the version being released as their Fix Version, that are not resolved or closed (i.e Unresolved), and do a bulk change (Top Right: Tools > Bulk Edit) and move them to the next release (under Unreleased Versions)
- Do a search for all tickets that have the version being released as their Fix Version, and export it as a CSV (Top Right: Export > CSV (All fields)
In Excel (or equivalent), delete the columns that aren't needed, that do some manipulation to get that list of bugs in the format for the release page(i.e \{% Jira XXXX %} Title)
For changes that need more description (e.g. big features), create sections on the release page and add those descriptions
Parameters of the release file (near the top) that must be set because this is a release candidate include:
...