paulononato/backstage
1
0
Fork 0
Code Issues Pull Requests Actions 27 Packages Projects Releases Wiki Activity

SECURITY,docs: move emergency release process docs to publishing.md + complete

Browse Source 
Co-authored-by: Johan Haals <johan.haals@gmail.com>
Signed-off-by: Patrik Oldsberg <poldsberg@gmail.com>
This commit is contained in:
Patrik Oldsberg
2022-01-12 11:32:19 +01:00
parent e6bef72496
commit 34d5570c78
2 changed files with 49 additions and 49 deletions
Download Patch File Download Diff File Expand all files Collapse all files
SECURITY.md
-17
View File
@@ -36,20 +36,3 @@ There are many situations where a vulnerability does not affect a particular dep
To work around this and other similar issues, Snyk provides a method to ignore vulnerabilities. In order to provide the best visibility and most utility to adopters of Backstage, we store these ignore rules in `.snyk` policy files. This allows adopters to rely on our ignore policies if they wish to do so.
Adding a new ignore policy is done by creating or modifying an existing `.snyk` file within a package root. See the [Snyk Documentation](https://support.snyk.io/hc/en-us/articles/360007487097-The-snyk-file) for details on the syntax. Always include a description, full path, and time limit of the ignore policy.
TODO: MOVE TO SEPARATE FILE
## Emergency Release Process
This emergency release process is intended only for the Backstage maintainers.
For this example we will be using the `@backstage/core` package which is currently version `1.5.0` in the master branch.
In the event of a severe bug or security vulnerability detected in `1.1.1` which was released in `2048-01-01` please proceed using this process.
- [ ] Create new base branch using `git checkout 2048-01-01 && git checkout -b release-2048-01-01-patch && git push --set-upstream origin release-2048-01-01-patch`
- [ ] Create new branch of the base branch(`release-2048-01-01-patch`) that will contain the emergency fix. `git checkout -b release-2048-01-01-emergency-fix`
- [ ] Apply fixes and generate new patch changeset for the effected package.
- [ ] Create PR towards the base branch(`release-2048-01-01-patch`) with the emergency fix.
- [ ] Review/Merge PR towards `release-2048-01-01-patch`. This will automatically trigger a release.
- [ ] Apply security fix towards master.
docs/plugins/publishing.md
+49 -32
View File
@@ -14,45 +14,62 @@ npm.
### Creating a new release
Version bumps are made through release PRs. To create a new release, checkout
out a new branch that you will use for the release, e.g.
Releases are handled by changesets and trigger whenever the "Version Packages"
PR is merged. This is typically done every Thursday around noon CET.
```sh
$ git checkout -b new-release
```
## Emergency Release Process
First bump the `CHANGELOG.md` in the root of the repo and commit. You bump it by
adding a header for the new version just below the `## Next Release` one.
**This emergency release process is intended only for the Backstage
maintainers.**
Then, from the root of the repo, run
For this example we will be using the `@backstage/plugin-foo` package as an
example and assume that it is currently version `1.5.0` in the master branch.
```sh
$ yarn release
```
In the event of a severe bug being introduced in version `1.5.0` of the
`@backstage/plugin-foo` released in the `2048-01-01` release, the following
processed is used to release an emergency fix as `1.5.1`:
This will bring up the lerna release CLI where you choose what type of version
bump you want to make, (major/minor/patch/prerelease). The CLI will take you
through choosing a version, previewing all changes, and then approving the
release. Once the release is approved, a new commit is created that you can
submit as a PR. Push the branch to GitHub:
- [ ] Identify the release that needs to be patched, in this case we're fixing a
broken release, so it would be the most recent one, `2048-01-01`. In the
event of a backported security fix, the release that has the last
published version of each major version of the package should be the one
patched.
- [ ] Make sure a patch branch exists for the release that is being patched. If
a patch already exists, reuse the existing branch.
```sh
$ git push origin -u new-release
```
```bash
git checkout release-2048-01-01
git checkout -b release-2048-01-01-patch
git push --set-upstream origin release-2048-01-01-patch
```
And then create a PR. Once the PR is approved and merged into master, the master
build will publish new versions of all bumped packages.
- [ ] With the `release-2048-01-01-patch` branch as a base, create a new branch
for your fix:
### Include new changes in existing release PR
```bash
git checkout -b ${USER}/release-2048-01-01-emergency-fix
```
If you want to include some last minute changes to an existing release PR,
follow these instructions:
- [ ] Apply fixes and create a new patch changeset for the effected package,
then commit these changes.
- [ ] Run `yarn release` in the root of the repo in order to convert your
changeset into package version bumps and changelog entries. Commit these
changes as a second `"Generated release"` commit.
- [ ] Create PR towards the base branch(`release-2048-01-01-patch`) containing
the two commits.
- [ ] Review/Merge PR into `release-2048-01-01-patch`. This will automatically
trigger a release.
- [ ] In the master branch, add a `.changeset/patched.json` to make sure that
future releases of the packages are bumped accordingly:
```sh
$ git checkout master
$ git pull
$ git checkout new-release
$ git reset --hard master
$ yarn release
$ git push --force
```
```json
{
"currentReleaseVersion": {
"@backstage/plugin-foo": "1.5.1"
}
}
```
- [ ] Apply the same fix towards master if needed and create appropriate
changeset. In the changeset towards master you should refer back to all
patch releases that also received the same fix.