npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

@kilianpaquier/semantic-release-backmerge

v1.6.2

Published

<p align="center"> <img alt="GitHub Release" src="https://img.shields.io/github/v/release/kilianpaquier/semantic-release-backmerge?include_prereleases&sort=semver&style=for-the-badge"> <img alt="GitHub Issues" src="https://img.shields.io/github/issues

Downloads

302

Readme

@kilianpaquier/semantic-release-backmerge


A semantic-release plugin to handle backmerge between branches.

| Step | Description | | ------------------ | --------------------------------------------------------------------------------------------- | | verifyConditions | Verify the presence of specific plugin configuration alongside required environment variables | | success | Apply backmerge for the appropriate target branches |

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

| name | required | default | description | | --------------- | -------- | ---------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | apiPathPrefix | Yes | Guessed in environment variables. Unless baseUrl is specifically provided. | API Prefix for your platform (i.e. /api/v4 for gitlab). | | baseUrl | Yes | Guessed in environment variables | Platform base URL (i.e. https://gitlab.com for gitlab). | | checkHasPull | No | true | Whether to check if a pull request already exists between a backmerged branch and the released branch. This check is only made if backmerge with git wasn't successful. | | commit | No | chore(release): merge branch ${ from } into ${ to } [skip ci] | Merge commit in case the fast-forward mode couldn't be done. | | dryRun | No | --dry-run option from semantic-release | Whether to really push and create pull requests or only log the actions. | | platform | Yes | Guessed in environment variables. Unless baseUrl is specifically provided. | Platform name. Either bitbucket, bitbucket-cloud, gitea, github or gitlab. | | targets | No | [] | Backmerge targets, a slice / list of { from: <from>, to: <to> }. from and to can be regexp like (develop\|staging) or v[0-9]+(.[0-9]+)?, etc. | | title | No | Automatic merge failure | Pull request title to set when creating pull requests. |

Templating

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

| name | type | description | | ----------- | ------ | ----------------------------------------------------------------------------------------------- | | from | string | Backmerge source branch. | | to | string | Backmerge target branch. | | lastRelease | object | Last release with version, gitTag, gitHead, name, and channels fields. | | nextRelease | object | Last release with version, gitTag, gitHead, name, type, channel and notes fields. |

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)

| variable name | description | | ------------------------------- | ------------------------------------------------------------------------------------------------------- | | BITBUCKET_URL | Base URL to your Bitbucket server | | BB_TOKEN or BITBUCKET_TOKEN | Bitbucket token to push backmerged branches (in case of HTTP(S) connection) or create pull requests |

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)

| variable name | description | | ------------------------------- | ------------------------------------------------------------------------------------------------------- | | BITBUCKET_CLOUD_URL | Base URL to your Bitbucket cloud server | | BB_TOKEN or BITBUCKET_TOKEN | Bitbucket token to push backmerged branches (in case of HTTP(S) connection) or create pull requests |

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

| variable name | description | | ------------- | ----------------------------------------------------------------------------------------------- | | GITEA_URL | Base URL to your gitea server | | GITEA_TOKEN | Gitea token to push backmerged branches (in case of HTTP(S) connection) or create pull requests |

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

| variable name | description | | -------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | GH_URL or GITHUB_URL or GITHUB_API_URL | Base URL to your github server, note that GITHUB_API_URL already exists with GitHub Actions | | GH_TOKEN or GITHUB_TOKEN | GitHub token to push backmerged branches (in case of HTTP(S) connection) or create pull requests |

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

| variable name | description | | ------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | GL_URL or GITLAB_URL or CI_SERVER_URL | Base URL to your gitlab server, note that CI_SERVER_URL already exists with GitLab CICD | | GL_TOKEN or GITLAB_TOKEN | GitLab token to push backmerged branches (in case of HTTP(S) connection) or create pull requests (api, read_repository and write_repository scopes) |

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