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

Continue renaming code from GitHub to Git

Browse Source 
Signed-off-by: Erik Engervall <erik.engervall@gmail.com>
This commit is contained in:
Erik Engervall
2021-04-29 12:02:05 +02:00
parent 66918b71fb
commit 19e6ebc1f2
38 changed files with 230 additions and 225 deletions
Download Patch File Download Diff File Expand all files Collapse all files
plugins/git-release-manager/README.md
+9 -9
View File
@@ -1,4 +1,4 @@
# GitHub Release Manager (GRM)
# Git Release Manager (GRM)
## Overview
@@ -6,17 +6,17 @@
Does it build and ship your code? **No**.
What `GRM` does is manage your **[releases](https://docs.github.com/en/github/administering-a-repository/managing-releases-in-a-repository)** on GitHub, building and shipping is entirely up to you as a developer to handle in your CI.
What `GRM` does is manage your Git **[releases](https://docs.github.com/en/github/administering-a-repository/managing-releases-in-a-repository)**, building and shipping is entirely up to you as a developer to handle in your CI.
`GRM` is built with industry standards in mind and the flow is as follows:
![](./src/features/Info/flow.png)
> **GitHub**: The source control system where releases reside in a practical sense. Read more about [GitHub releases](https://docs.github.com/en/github/administering-a-repository/managing-releases-in-a-repository). (Note that this plugin works just as well with GitHub Enterprise.)
> **Git**: The source control system where releases reside in a practical sense. Read more about [Git releases](https://docs.github.com/en/github/administering-a-repository/managing-releases-in-a-repository). (Note that this plugin works just as well with any system implementing `Git`.)
>
> **Release Candidate (RC)**: A GitHub pre-release intended primarily for internal testing
> **Release Candidate (RC)**: A Git pre-release intended primarily for internal testing
>
> **Release Version**: A GitHub release intended for end users
> **Release Version**: A Git release intended for end users
Looking at the flow above, a common release lifecycle could be:
@@ -24,7 +24,7 @@ Looking at the flow above, a common release lifecycle could be:
- `GRM`
1. Creates a release branch `rc/<version>`
1. Creates Release Candidate tag `rc-<version>`
1. Creates a GitHub prerelease with Release Candidate tag
1. Creates a Git prerelease with Release Candidate tag
- Your CI
1. Detects the new tag by matching the git reference `refs/tags/rc-.*`
1. Builds and deploys to staging environment for testing
@@ -32,14 +32,14 @@ Looking at the flow above, a common release lifecycle could be:
- `GRM`
1. The selected commit is cherry-picked to the release branch
1. The release tag is bumped
1. Updates GitHub release's tag and description with the patch's details
1. Updates Git release's tag and description with the patch's details
- Your CI
1. Detects the new tag by matching the git reference `refs/tags/(rc|version)-.*` (Release Versions are patchable as well)
1. Builds and deploys to staging (or production if Release Version) for testing
- User presses **Promote Release Candidate to Release Version**
- `GRM`
1. Creates Release Version tag `version-<version>`
1. Promotes the GitHub release by removing the prerelease flag
1. Promotes the Git release by removing the prerelease flag
- Your CI
1. Detects the new tag by matching the git reference `refs/tags/version-.*`
1. Builds and deploys to production for testing
@@ -48,7 +48,7 @@ Looking at the flow above, a common release lifecycle could be:
### Importing
The plugin exports a single full-page extension `GitHubReleaseManagerPage`, which one can add to an app like a usual top-level tool on a dedicated route.
The plugin exports a single full-page extension `GitReleaseManagerPage`, which one can add to an app like a usual top-level tool on a dedicated route.
### Configuration