Download
Users will need to be able to download our release assets, e.g. binaries, installers and packages. We will use the GitLab package registry to host our release assets.
Releases
Whenever we release, we will upload our release assets to the GitLab package registry. The assets will be uploaded twice, once with the version tag and once with the "latest" tag. The purpose of the "latest" tag is to ensure we can permanently link to the latest version of our assets from our website. We will not have to update the download links everytime we release.
Release Schedule
In the Deployment of Production Environment section on the Database page of this guide, we already created a pipeline schedule to release web on every 4th Sunday. We will similarly now create pipeline schedules for releases of the other platforms.
Create a pipeline schedule for the desktop release. Follow the same instructions as before but this time with the following differences:
- Set the "Description" to "Release - Desktop"
- Set the "Interval Pattern" to "0 0 * * SUN%4+1"
- Set the variable "RELEASE" to "Desktop"
Do the same for the Linux and mobile releases, each time incrementing the number after "SUN%4+" by 1, i.e. "SUN%4+2" for Linux and "SUN%4+3" for mobile. This ensures that there is only one release every Sunday and there are no overlapping releases.
Finally you should have pipeline schedules for all releases:
Web
In the case of web, we don't have any assets for users to download. However it will still be useful to create releases in order to have snapshots of known working versions, i.e. on which release testing was done. The tags will also let us know which version of the source code was in production at which point in time.
In the Deployment of Production Environment section on the Database page of this guide, we already created a CI pipeline stage to automatically deploy to production whenever we do a web release.
We will now add another pipeline stage to formalize the web release, i.e. to create a Git tag and to create a release in GitLab. Modify your .gitlab-ci.yml as per the below. Add the "release-web" stage after the "deploy-production-environment" stage in the CI pipeline.
stages:
- release-web
include:
- local: "ci/release-web.yml"
In the "ci" directory of your Git repository, add a file named "release-web.yml" and add the below content:
release-web:
before_script:
- VERSION=$(echo $CI_PIPELINE_CREATED_AT | cut -d'T' -f1 | sed 's/-/./g')
image: registry.gitlab.com/gitlab-org/release-cli:latest
rules:
- if: $RELEASE == "Web"
script:
release-cli create --name "Web-$VERSION" --tag-name "Web-$VERSION"
stage: release-web
The above pipeline stage only runs when the environment variable "RELEASE" is set to "Web". Earlier, in the Deployment of Production Environment section on the Database page of this guide we created a scheduled pipeline which will execute every 4th Sunday with that environment variable set to "Web".
In the above pipeline stage a new Git tag is created when we release. By default, newly created Git tags trigger the pipeline. To prevent our CI stages from executing again we must add the following rule to all CI stages except for stages that already have rules to execute only on merge to the main branch or on release:
rules:
- if: $CI_COMMIT_TAG
when: never
- when: always
Desktop
We will now add another pipeline stage to create a release for the desktop platforms, Windows and macOS. Whilst Linux is also a desktop platform, it gets its own releases. See the Cadence section on the Releases page of this guide for more details.
Modify your .gitlab-ci.yml as per the below. Add the "release-desktop" stage after the "release-web" stage in the CI pipeline.
stages:
- release-desktop
include:
- local: "ci/release-desktop.yml"
In the "ci" directory of your Git repository, add a file named "release-desktop.yml" and add the below content:
release-desktop:
before_script:
- apk add curl zip
- VERSION=$(echo $CI_PIPELINE_CREATED_AT | cut -d'T' -f1 | sed 's/-/./g')
- WINDOWS_BINARY_PATH=app/src-tauri/target/x86_64-pc-windows-msvc/release
- WINDOWS_BINARY_NAME=epic-fantasy-forge.exe
- WINDOWS_INSTALLER_PATH=app/src-tauri/target/x86_64-pc-windows-msvc/release/bundle/nsis
- WINDOWS_INSTALLER_NAME=epic-fantasy-forge-setup.exe
- MACOS_APP_PATH=app/src-tauri/target/release/bundle/macos
- MACOS_APP_NAME=epic-fantasy-forge.app
- MACOS_ZIP_NAME=epic-fantasy-forge.app.zip
- MACOS_DMG_PATH=app/src-tauri/target/release/bundle/dmg
- MACOS_DMG_NAME=epic-fantasy-forge.dmg
- PACKAGE_REGISTRY_URL=$CI_API_V4_URL/projects/$CI_PROJECT_ID/packages/generic
- mv $WINDOWS_INSTALLER_PATH/epic-fantasy-forge_*.exe $WINDOWS_INSTALLER_PATH/$WINDOWS_INSTALLER_NAME
- mv $MACOS_DMG_PATH/epic-fantasy-forge_*.dmg $MACOS_DMG_PATH/$MACOS_DMG_NAME
- zip -r $MACOS_APP_PATH/$MACOS_ZIP_NAME $MACOS_APP_PATH/$MACOS_APP_NAME
image: registry.gitlab.com/gitlab-org/release-cli:latest
rules:
- if: $RELEASE == "Desktop"
script:
- |
curl --header "JOB-TOKEN: $CI_JOB_TOKEN" --upload-file $WINDOWS_BINARY_PATH/$WINDOWS_BINARY_NAME "$PACKAGE_REGISTRY_URL/windows/latest/$WINDOWS_BINARY_NAME"
- |
curl --header "JOB-TOKEN: $CI_JOB_TOKEN" --upload-file $WINDOWS_BINARY_PATH/$WINDOWS_BINARY_NAME "$PACKAGE_REGISTRY_URL/windows/$VERSION/$WINDOWS_BINARY_NAME"
- |
curl --header "JOB-TOKEN: $CI_JOB_TOKEN" --upload-file $WINDOWS_INSTALLER_PATH/$WINDOWS_INSTALLER_NAME "$PACKAGE_REGISTRY_URL/windows-installer/latest/$WINDOWS_INSTALLER_NAME"
- |
curl --header "JOB-TOKEN: $CI_JOB_TOKEN" --upload-file $WINDOWS_INSTALLER_PATH/$WINDOWS_INSTALLER_NAME "$PACKAGE_REGISTRY_URL/windows-installer/$VERSION/$WINDOWS_INSTALLER_NAME"
- |
curl --header "JOB-TOKEN: $CI_JOB_TOKEN" --upload-file $MACOS_APP_PATH/$MACOS_ZIP_NAME "$PACKAGE_REGISTRY_URL/macos/latest/$MACOS_ZIP_NAME"
- |
curl --header "JOB-TOKEN: $CI_JOB_TOKEN" --upload-file $MACOS_APP_PATH/$MACOS_ZIP_NAME "$PACKAGE_REGISTRY_URL/macos/$VERSION/$MACOS_ZIP_NAME"
- |
curl --header "JOB-TOKEN: $CI_JOB_TOKEN" --upload-file $MACOS_DMG_PATH/$MACOS_DMG_NAME "$PACKAGE_REGISTRY_URL/macos-dmg/latest/$MACOS_DMG_NAME"
- |
curl --header "JOB-TOKEN: $CI_JOB_TOKEN" --upload-file $MACOS_DMG_PATH/$MACOS_DMG_NAME "$PACKAGE_REGISTRY_URL/macos-dmg/$VERSION/$MACOS_DMG_NAME"
- |
release-cli create --name "Desktop-$VERSION" --tag-name "Desktop-$VERSION" \
--assets-link "{\"name\":\"$WINDOWS_BINARY_NAME\",\"url\":\"$PACKAGE_REGISTRY_URL/windows/$VERSION/$WINDOWS_BINARY_NAME\", \"link_type\":\"package\"}" \
--assets-link "{\"name\":\"$WINDOWS_INSTALLER_NAME\",\"url\":\"$PACKAGE_REGISTRY_URL/windows-installer/$VERSION/$WINDOWS_INSTALLER_NAME\", \"link_type\":\"package\"}" \
--assets-link "{\"name\":\"$MACOS_ZIP_NAME\",\"url\":\"$PACKAGE_REGISTRY_URL/macos/$VERSION/$MACOS_ZIP_NAME\", \"link_type\":\"package\"}" \
--assets-link "{\"name\":\"$MACOS_DMG_NAME\",\"url\":\"$PACKAGE_REGISTRY_URL/macos-dmg/$VERSION/$MACOS_DMG_NAME\", \"link_type\":\"package\"}"
stage: release-desktop
The above CI stage uploads our Windows and macOS build artifacts to the GitLab package registry. Then it creates a release where the items just uploaded to the package registry are linked against as part of the release assets.