oss/syft
2
0
Fork 0
mirror of https://github.com/anchore/syft.git synced 2025-11-17 16:33:21 +01:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #352 from anchore/enable-release-environment

Browse Source 
Enable manual release approval
This commit is contained in:
Alex Goodman 2021-03-25 12:13:41 -04:00 committed by GitHub
commit cedf8cd6d7
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 10 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
.github/workflows/release.yaml vendored
View File

@ -12,7 +12,8 @@ env:
GO_VERSION: "1.16.x" GO_VERSION: "1.16.x"
jobs: jobs:
wait-for-checks: quality-gate:
environment: release
runs-on: ubuntu-latest # This OS choice is arbitrary. None of the steps in this job are specific to either Linux or macOS. runs-on: ubuntu-latest # This OS choice is arbitrary. None of the steps in this job are specific to either Linux or macOS.
steps: steps:
- uses: actions/checkout@v2 - uses: actions/checkout@v2
@ -90,7 +91,7 @@ jobs:
false false
release: release:
needs: [wait-for-checks] needs: [quality-gate]
runs-on: macos-latest # Due to our code signing process, it's vital that we run our release steps on macOS. runs-on: macos-latest # Due to our code signing process, it's vital that we run our release steps on macOS.
steps: steps:
- uses: docker-practice/actions-setup-docker@v1 - uses: docker-practice/actions-setup-docker@v1

12
RELEASE.md
View File

@ -89,11 +89,13 @@ This release process itself should be as automated as possible, and have only a
milestone with a partial version, the full version should be used for the git tag (e.g. milestone with a partial version, the full version should be used for the git tag (e.g.
with a Milestone of `v0.1` the tag should be `v0.1.0`). with a Milestone of `v0.1` the tag should be `v0.1.0`).
1. Push the tag, the release pipeline will generate and publish all assets as well as a 1. Push the tag.
draft GitHub Release.
1. A release admin must approve the release on the GitHub Actions release pipeline run page.
Once approved, the release pipeline will generate all assets and draft a GitHub Release.
1. Promote the GitHub Release from draft to public. Note: since extra assets are made 1. Navigate to the GitHub Release draft page to review the final changelog and publish the
available immediately from previous steps (i.e. the brew formula) the release should release. Once published, a release-follow-up pipeline will publish derivative artifacts
only be in this state for a small amount of time (minutes). (docker image to DockerHub, brew formula to the external homebrew git repo, etc).
1. If there is a release Milestone, close it. 1. If there is a release Milestone, close it.