The steps used during the release process, including release candidates
Before a release it is required that a release candidate version is created. This allows the Threat Dragon community to review and feedback on the proposed release. Changes that are agreed for the release should then be made available with a further release candidate.
For example if RC1, but change for RC2 and so on :
git clone [email protected]:OWASP/threat-dragon.git
cd threat-dragon
- update version, for example
"version": "2.3.0",
, intd.vue/package.json
- ensure
buildState
intd.vue/package.json
is-RC1
- update version, for example
"version": "2.3.0-RC1",
, inpackage.json
andtd.server/package.json
- update package lock files:
npm install
npm run build
npm test
npm run test:vue
- ensure that the package-lock files are up to date using
npm install
git add --all; git status
git commit -m"release version 2.3.0-RC1"
git push
- tag the release
git tag v2.3.0-RC1
git push origin v2.3.0-RC1
repeat as necessary for further release candidates.
The github release workflow will then create the release candidate along with the install images
Ensure the release candidate is announced on the OWASP Threat Dragon slack channel and any other relevant channels
After the releases candidate has been agreed by the Threat Dragon community, a release version can be prepared:
git clone [email protected]:OWASP/threat-dragon.git
cd threat-dragon
- update version eg
"version": "2.3.0",
, inpackage.json
,td.vue/package.json
andtd.server/package.json
- update
buildState
intd.vue/package.json
away from-latest
to '' - update package lock files:
npm install
npm run build
npm test
npm run test:vue
- ensure that the package-lock files are up to date using
npm install
git add --all; git status
git commit -m"release version 2.3.0"
git push
- tag the release
git tag v2.3.0
git push origin v2.3.0
The github release workflow then creates the draft release and the install images
- once tagged, the github workflow pushes the docker image to docker hub
- check using
docker pull threatdragon/owasp-threat-dragon:v2.3.0
- Test using the command to run a detached container:
docker run -d -p 8080:3000 -v $(pwd)/.env:/app/.env threatdragon/owasp-threat-dragon:v2.3.0
- Ideally test this release on Windows, linux and MacOS using
http://localhost:8080/#/
If the image tests correctly, promote the docker image
from dockerhub threatdragon/
to dockerhub OWASP/threat-dragon/v2.3.0
.
There is no going back on this last step, so it is deliberately left as a manual task:
docker pull --platform linux/x86_64 threatdragon/owasp-threat-dragon:v2.3.0
docker tag threatdragon/owasp-threat-dragon:v2.3.0 owasp/threat-dragon:v2.3.0
docker push owasp/threat-dragon:v2.3.0
docker pull owasp/threat-dragon:v2.3.0
docker tag owasp/threat-dragon:v2.3.0 owasp/threat-dragon:stable
docker push owasp/threat-dragon:stable
ensure the tag now exists within the OWASP Docker hub: https://hub.docker.com/r/owasp/threat-dragon/tags
- Install Heroku CLI tools if necessary
- Login to Heroku
- Inspect logs using
heroku logs --app=threatdragon-v2 --tail
- Ensure no rollback shown in dashboard
- Download desktop AppImage for Linux and installers for MacOS
.dmg
and Windows.exe
- Download the
latest*.yml
auto-update checksum files - Create SHA512
checksum*.yml
files:
grep sha512 latest-linux.yml | head -n 2 | tail -n 1 | cut -d ":" -f 2 | base64 -d | \
hexdump -ve '1/1 "%.2x"' >> checksum-linux.yml
grep sha512 latest.yml | head -n 2 | tail -n 1 | cut -d ":" -f 2 | base64 -d | \
hexdump -ve '1/1 "%.2x"' >> checksum.yml
grep sha512 latest-mac.yml | head -n 3 | tail -n 1 | cut -d ":" -f 2 | base64 -d | \
hexdump -ve '1/1 "%.2x"' >> checksum-mac.yml
grep sha512 latest-mac.yml | head -n 4 | tail -n 1 | cut -d ":" -f 2 | base64 -d | \
hexdump -ve '1/1 "%.2x"' >> checksum-mac-arm64.yml
- Confirm SHA512 with:
echo "$(cat checksum-linux.yml) Threat-Dragon-ng-2.3.0.AppImage" | sha512sum --check
echo "$(cat checksum-mac.yml) Threat-Dragon-ng-2.3.0.dmg" | sha512sum --check
echo "$(cat checksum-mac-arm64.yml) Threat-Dragon-ng-2.3.0-arm64.dmg" | sha512sum --check
echo "$(cat checksum.yml) Threat-Dragon-ng-Setup-2.3.0.exe" | sha512sum --check
- upload
checksum*.yml
files
Before adding text to the draft release, click on 'Generate Release Notes' button from the edit window. If this is done after text is added it does not work. Edit the 'What's Changed' to filter out any chores.
Then update the release notes for the draft in the Threat Dragon release area
using the release notes using markdown provided by .release-note-template.md
as a template,
making sure to revise 2.x.x
to the correct version number such as 2.3.0
Promote the release from draft to public once everything is in place
Update the releases tab and the info pane on the OWASP Threat Dragon project pages.
Finally ensure Threat Dragon announces the new release on the OWASP Threat Dragon slack channel and any other relevant channels
It used to be that altool could be used to notarize the MacOS .dmg
files in the pipeline.
As of early 2024 this is no longer available and notarytool must be used in a secure environment.
Used in the pipeline, it can also be done/checked manually:
- Download both x86 and arm64 images for the MacOS installer (
*.dmg
) - ensure that the apple developer environment is set up
- notarize and staple, for example with version 2.3.0:
xcrun notarytool submit --apple-id <apple-account-email> --team-id <teamid> \
--password <password> --verbose --wait Threat-Dragon-ng-2.3.0-arm64.dmg
xcrun stapler staple --verbose Threat-Dragon-ng-2.3.0-arm64.dmg
- similarly for the x86 image
Threat-Dragon-ng-2.3.0.dmg
https://snapcraft.io/install/threat-dragon/arch https://login.ubuntu.com/
Full name: Threat Dragon
username: threat-dragon
snapcraft login
using email: [email protected] and Ubuntu One password?
Token used in the Threat Dragon pipeline as 'SNAPCRAFT_TOKEN', use command to refresh creds:
snapcraft export-login --snaps threat-dragon --channels stable