From 27f7599a1ebe2e8b32f261ab00402d0143535df6 Mon Sep 17 00:00:00 2001 From: Florian Scholdei Date: Tue, 17 Sep 2024 13:58:36 +0200 Subject: [PATCH] Fix headings in documentation Pushed-by: Florian Scholdei Co-authored-by: Florian Scholdei Committed-by: Florian Scholdei --- docs/en/development/architecture-overview.md | 4 +- docs/en/development/cli-guideline.md | 4 +- docs/en/release-process.md | 48 +++++++++++--------- 3 files changed, 32 insertions(+), 24 deletions(-) diff --git a/docs/en/development/architecture-overview.md b/docs/en/development/architecture-overview.md index 7ca7babae4..344bd622af 100644 --- a/docs/en/development/architecture-overview.md +++ b/docs/en/development/architecture-overview.md @@ -1,4 +1,6 @@ -# SCM-Manager architecture overview +--- +title: Architecture overview +--- ## Introduction This document does not describe the modules of SCM-Manager nor does it explain the technologies that are used. diff --git a/docs/en/development/cli-guideline.md b/docs/en/development/cli-guideline.md index 2aeaeaf92b..c828275bee 100644 --- a/docs/en/development/cli-guideline.md +++ b/docs/en/development/cli-guideline.md @@ -1,4 +1,6 @@ -# CLI Guidelines +--- +title: CLI Guidelines +--- ## Resource centered api Every new command group starts with the resource name like `repo`. diff --git a/docs/en/release-process.md b/docs/en/release-process.md index 6f9366fb31..61a48f0abf 100644 --- a/docs/en/release-process.md +++ b/docs/en/release-process.md @@ -1,4 +1,8 @@ -# How to release SCM-Manager core (Script) +--- +title: Release process +--- + +## How to release SCM-Manager core (Script) The most easy way to release the core is to use the release script. This will guide you through all necessary tasks. @@ -21,12 +25,12 @@ It will - Create a commit with the changes, and - Create and push the release branch. -# Manual core release +## Manual core release To release a new version of SCM-Manager "manually", you have to do the following steps (replace placeholders `` accordingly, eg. with `2.1.0`): -## Check out default branch +### Check out default branch Make sure you have no changes you want to keep! @@ -34,7 +38,7 @@ Make sure you have no changes you want to keep! git fetch && git checkout -f origin/develop && git clean -fd && git checkout -B develop ``` -## Merge support branch +### Merge support branch Check whether there is an integration branch for the previous release or bugfixes not merged into the develop branch. Merge them now. @@ -42,7 +46,7 @@ Check whether there is an integration branch for the previous release or bugfixe git merge origin/support/ ``` -## Update Changelog +### Update Changelog The changelog must be updated to reflect the changes for the new release. All unreleased changes are stored in the `gradle/changelog` directory. @@ -63,7 +67,7 @@ git diff CHANGELOG.md If everything looks fine, we can remove the changelog directory. -## Create release branch, commit changes and push +### Create release branch, commit changes and push ```bash git rm -rf gradle/changelog \ @@ -73,7 +77,7 @@ git rm -rf gradle/changelog \ && git push origin release/$VERSION ``` -## Wait for Jenkins build +### Wait for Jenkins build Jenkins will @@ -83,15 +87,15 @@ Jenkins will - set the new development version for the develop branch - delete the release branch -## Make a party +### Make a party -# Hotfix Releases of SCM-Manager +## Hotfix Releases of SCM-Manager To release a hotfix version of SCM-Manager (or in other words a version, that is not based on the current `develop` branch but on an older tag), there is a bit more manual work to do and there is no one-fits-all way, so consider each step carefully and don't take this as a copy-paste manual like the normal release. -## Create hotfix branch +### Create hotfix branch To trigger the release, create a hotfix branch on the tag you want to create the hotfix for (lets say, that's version `2.30.0`) and prepare the release like above: @@ -115,7 +119,7 @@ git push origin hotfix/2.30.1 Jenkins will build and release the versions, create the new tag, but **will not** update the `main` or `develop` branches. So these updates come next. -## Update Branches +### Update Branches Depending on whether you released a hotfix for an older version or the latest release, you have to update the `main` branch to the new tag. So in our example, if there is no version `2.31.x` yet, the new version @@ -144,11 +148,11 @@ How these conflicts should be merged depends on the version that has been releas - If the hotfix is the new main, you should take this new version and then manually create a new SNAPSHOT based on the new hotfix version number using gradle: `./gradlew setVersionToNextSnapshot`. -# How to release SCM-Manager plugins +## How to release SCM-Manager plugins To release a new version of a Plugin for SCM-Manager you have to do the following steps (replace placeholder `` accordingly, eg. with `2.1.0`): -## Check out default branch +### Check out default branch Make sure you have no changes you want to keep! @@ -156,7 +160,7 @@ Make sure you have no changes you want to keep! git fetch && git checkout -f origin/develop && git clean -fd && git checkout -B develop ``` -## Merge support branch +### Merge support branch Check whether there is an integration branch for the previous release or bugfixes not merged into the develop branch. Merge them now. @@ -164,18 +168,18 @@ Check whether there is an integration branch for the previous release or bugfixe git merge origin/support/ ``` -## Update SCM parent if necessary +### Update SCM parent if necessary If you need to update the parent of the plugin to a new release of SCM-Manager, change it now: - `build.gradle`: `scmVersion` - `package.json`: `dependencies.ui-plugins` -## Plugin dependencies +### Plugin dependencies Check if all plugin dependencies are proper versions and not SNAPSHOT! -## Build, commit and push +### Build, commit and push This step is only needed, when you had to update the version in the prior step. If the core version has not been increased, this step can be skipped. @@ -189,7 +193,7 @@ If the core version has not been increased, this step can be skipped. Wait for Jenkins to be green. -## Update Changelog +### Update Changelog The changelog must be updated to reflect the changes for the new release. All unreleased changes are stored in the `gradle/changelog` directory. @@ -208,7 +212,7 @@ Now we should manually check if the changelog looks good. git diff CHANGELOG.md ``` -## Create, commit and push release branch +### Create, commit and push release branch This step needs the `VERSION` set in the step above. @@ -220,7 +224,7 @@ git rm -rf gradle/changelog \ && git push origin release/$VERSION ``` -## Wait for Jenkins build +### Wait for Jenkins build Jenkins will @@ -230,13 +234,13 @@ Jenkins will - set the new development version for the develop branch - delete the release branch -## Attention: Creating new plugins +### Attention: Creating new plugins If you are creating a new plugin which doesn't exist in the SCM-Manager Plugin-Center yet, your plugin will not be shown after the release. First you have to create a `plugin.yml` in the website repository. Example: https://github.com/scm-manager/website/blob/master/content/plugins/scm-teamscale-plugin/plugin.yml -## Hotfix Release +### Hotfix Release The release of a hotfix version is still a partly manual process that requires some knowledge of git and the versioning of SCM-Manager. Here is a helping hand as a guideline of how to release