@kilianpaquier/semantic-release-backmerge v1.5.3

@kilianpaquier/semantic-release-backmerge

A semantic-release plugin to handle backmerge between branches.

• How to ?
• How does it work ?
• Usage
• Configuration
  • Templating
  • Maintenance branches
• Environment variables
  • Bitbucket (data center/server)
  • Bitbucket (cloud)
  • Gitea
  • Github
  • Gitlab

How to ?

bun

bun install -D @kilianpaquier/semantic-release-backmerge

npm

npm install -D @kilianpaquier/semantic-release-backmerge

pnpm

pnpm install -D @kilianpaquier/semantic-release-backmerge

yarn

yarn install -D @kilianpaquier/semantic-release-backmerge

How does it work ?

When configured in targets, a provided branch (i.e main) can be backmerged in one or multiple others (i.e. develop) when a released in made with semantic-release.

With the instance of main and develop, develop branch will be check'ed out locally and merged with git merge <branch> --ff -m <commit_message>. It means that if git can avoid a merge commit, it will avoid it.

In the event of conflicts (it may happen, production fixes could be made to main and features developped in develop), a pull request is created from main to develop.

Usage

This plugin can be configured through the semantic-release configuration file.

{
  "branches": ["main"],
  "plugins": [
    "@semantic-release/commit-analyzer",
    "@semantic-release/release-notes-generator",
    "@semantic-release/git",
    "@semantic-release/github",
    [
      "@kilianpaquier/semantic-release-backmerge",
      {
        "commit": "chore(release): merge branch ${ from } into ${ to } [skip ci]",
        "targets": [
          { "from": "main", "to": "develop" }
          { "from": "main", "to": "staging" }
          { "from": "staging", "to": "develop" }
        ],
        "title": "Automatic merge failure",
      }
    ],
    "@semantic-release/exec",
  ]
}

Configuration

Templating

Configuration commit and title are templated with lodash during backmerge or pull request creation. The following data are available:

Maintenance branches

In some cases, you may want to maintain multiple maintenance branches associated to the same major version.

In that case, semantic-release-backmerge is covering for you. When providing a from branch matching a maintenance branch, then backmerge will only allow backmerge into more recent maintenance branches (of the same major version):

• v1 cannot be backmerged
• v1.6 can be backmerged into v1.7 (and above) and v1
• v1.x cannot be backmerged
• v1.5.x can be backmerged into v1.6.x (and above) and v1.x

Environment variables

When working with specifics git platforms, and as such sometimes with associated CI functionalities, environment variable are by default provided.

For semantic-release-backmerge to work flawlessly with your platform, you may provide in the next sections the right environment variables.

To avoid painful configurations, you may use the environments variables to automatically guess baseUrl, apiPathPrefix and platform instead of given them in your configuration file.

Bitbucket (data center/server)

Notes:

• The Base URL name differs from bitbucket (cloud) because the API endpoints to create pull request aren't the same.
• When BITBUCKET_URL is provided, you may omit the following configuration variables:
  • baseUrl is given this URL
  • apiPathPrefix is given by default /rest/api/1.0
  • platform is set to bitbucket
• Endpoint to create pull requests is POST {baseUrl}{apiPathPrefix}/projects/{owner}/repos/{name}/pull-requests
  • Example: POST https://stash.company.com/rest/api/1.0/projects/kilianpaquier/repos/semantic-release-backmerge/pull-requests
  • See documentation

Bitbucket (cloud)

Notes:

• The Base URL name differs from bitbucket (data center/server) because the API endpoints to create pull request aren't the same.
• When BITBUCKET_CLOUD_URL is provided, you may omit the following configuration variables:
  • baseUrl is given this URL
  • apiPathPrefix is given by default /2.0
  • platform is set to bitbucket-cloud
• Endpoint to create pull requests is POST {baseUrl}{apiPathPrefix}/repositories/{owner}/{name}/pullrequests
  • Example: POST https://company.bitbucket.org/2.0/repositories/kilianpaquier/semantic-release-backmerge/pullrequests
  • See documentation

Gitea

Notes:

• When GITEA_URL is provided, you may omit the following configuration variables:
  • baseUrl is given this URL
  • apiPathPrefix is given by default /api/v1
  • platform is set to gitea
• Endpoint to create pull requests is POST {baseUrl}{apiPathPrefix}/repos/{owner}/{name}/pulls
  • Example: POST https://company.gitea.com/api/v1/repos/kilianpaquier/semantic-release-backmerge/pulls
  • See documentation

Github

Notes:

• When GH_URL or GITHUB_URL or GITHUB_API_URL is provided, you may omit the following configuration variables:
  • baseUrl is given this URL
  • apiPathPrefix is given by default ""
  • platform is set to github
• Endpoint to create pull requests is POST {baseUrl}{apiPathPrefix}/repos/{owner}/{repo}/pulls
  • Example: POST https://api.github.com/repos/kilianpaquier/semantic-release-backmerge/pulls
  • See documentation

Gitlab

Notes:

• When GL_URL or GITLAB_URL or CI_SERVER_URL is provided, you may omit the following configuration variables:
  • baseUrl is given this URL
  • apiPathPrefix is given by default /api/v4
  • platform is set to gitlab
• Endpoint to create pull requests is POST {baseUrl}{apiPathPrefix}/projects/{uri_encoded({owner}/{repo})}/merge_requests
  • Example: POST https://gitlab.company.com/api/v4/projects/kilianpaquier%2Fsemantic-release-backmerge/merge_requests
  • Example: POST https://gitlab.company.com/api/v4/projects/kilianpaquier%2Fsubgroup%2Fsemantic-release-backmerge/merge_requests
  • See documentation