Fedora Release (Modern)
Introduction
This assume you have a working setup already. See the fedoraproject.org repository for instructions. |
This document guides you through updating the websites for a release (beta or GA) of Fedora.
Make sure your changes are made on the |
Releases information
First, you need to edit the release.yml file either directly from git, or using the CMS (recommended).
If you are updating for a beta release, then make sure to flip the "Display Beta Download" toggle in the CMS, or set the beta.enabled
flag in the release.yml
file to true
.
This toggles whether we show the beta download links at all.
Bump the release version and set the release candidate version to the RC that was called gold/ready for release. Find this information out from releng, if necessary.
For GA release, you’ll need to update the Release Date and the Fedora Magazine announcement post as well.
Cloud AMI list
You’ll need to update the Fedora Cloud AMI list using the fetch_amis.py
script:
./fetch_amis.py ../content/release.yml ../content/editions/cloud/ami_list.yml
The AMI list will be updated in /content/editions/cloud/ami_list.yml
. Add that file to your commit.
Fedora Media Writer
TODO: Update this section for the new fedoraproject.org website |
The next step is to produce the releases.json
static file used by Fedora Media
Writer to produce its list of possible downloads. In the fmw
section of
release.yaml
, update the releases_json
list to include the current non-EOL
versions of Fedora, including any current betas. If a version is in beta, set
the its milestone
to beta
. Otherwise set it to final
or leave out the
field altogether.
For example:
fmw:
...
releases_json:
- version: 31
milestone: beta
- version: 30
- version: 29
Once this is done, you’ll need to actually generate the releases.json
file.
If using a containerized environment, you can do this from the root of the
repository (replacing sudo docker
with podman
if you use Podman):
sudo docker run -it --rm -v "$(pwd):/opt/:z" fedora-websites python ./scripts/releases-json.py > sites/getfedora.org/static/releases.json
Otherwise, if you’re not using a containerized environment, you can run the
script yourself after installing the python-fedfind
package. From the root of
the repository:
python3 sites/getfedora.org/scripts/releases-json.py > sites/getfedora.org/static/releases.json
Check that releases.json looks sane (it should look like a blob of JSON), then move on.
GPG Keys
Lastly, you’ll want to add the latest GPG key information to gpg_keys
in
security.yml
or with the CMS. Follow the pattern that is already there, and move any now-EOL releases into the obsolete
subsection.
Release day
On release day (or the day before), you can check that all download links are good with the check_link.py script. This uses the release information from the release.yaml
file.
./check_link.py
Checking download artifacts...
Cloud:
[OK] https://dl.fedoraproject.org/pub/fedora/linux/releases/38/Cloud/aarch64/images/Fedora-Cloud-Base-38-1.6.aarch64.qcow2
[OK] https://dl.fedoraproject.org/pub/fedora/linux/releases/38/Cloud/aarch64/images/Fedora-Cloud-Base-38-1.6.aarch64.raw.xz
[...]
***********************
All Good!
If any artifact is flagged as missing, contact releng/infra team.
Conclusion
That should be all. The old sites (namely spins, labs, alt, arm) which haven’t been ported to the new system need to be updated separately and are beyond the scope of this document.
Commit your changes on the develop
branch, make sure everything looks good on the GitLab pages, then use Merge Request to deploy to staging & prod.
Want to help? Learn how to contribute to Fedora Docs ›