go-semantic-release/ semantic-release

(v2.13.0) 4 months ago

Shell

gitlab-ci

semver

semantic-release

gitlab

JavaScript

GitHub

semantic-versioning

github-actions

View on GitHub

Need help with semantic-release?

Click the “chat” button below for chat support from the developer who created it, or find similar developers for support.

About the developer

go-semantic-release

113 Stars

29 Forks

MIT License

254 Commits

12 Opened issues

Description

📦🚀 semantic-release written in go

Services available

Need anything else?

Contributors list

Readme

:package::rocket: semantic-release

Name: semantic-release
Brand: semantic-release
SKU: //go-semantic-release/semantic-release
Rating: 2.0325 (113 reviews)

fully automated package/module/image publishing

A more lightweight and standalone version of semantic-release.

🚨 Upgrade to semantic-release v2 🚨

semantic-release

v2 is now available. If you run into any problems, please create a GitHub issue. You can always downgrade to v1 with:

curl -SL https://get-release.xyz/semantic-release/linux/amd64/1.22.1 -o ./semantic-release && chmod +x ./semantic-release

Breaking changes

It is now necessary to use double dashes for CLI flags (e.g.
```
--dry
```
)
Travis CI support has been removed
Some CLI flags have changed:

| v1 | v2 | |:--------------------------:|:------------------------------------------------:| |

-vf

-f

| |

--noci

--no-ci

| |

--ghe-host

--provider-opt "github_enterprise_host="

| |

--travis-com

| removed | |

--gitlab

--provider gitlab

| |

--gitlab-base-url

--provider-opt "gitlab_baseurl="

| |

--gitlab-project-id

--provider-opt "gitlab_projectid="

| |

--slug

--provider-opt "slug="

How does it work?

Instead of writing meaningless commit messages, we can take our time to think about the changes in the codebase and write them down. Following the AngularJS Commit Message Conventions it is then possible to generate a helpful changelog and to derive the next semantic version number from them.

When

semantic-release

is setup it will do that after every successful continuous integration build of your default branch and publish the new version for you. This way no human is directly involved in the release process and your releases are guaranteed to be unromantic and unsentimental.

Source: semantic-release/semantic-release#how-does-it-work

You can enforce semantic commit messages using a git hook.

Installation

Option 1: Use the go-semantic-release GitHub Action (go-semantic-release/action)

Option 2: Install

semantic-release

manually

curl -SL https://get-release.xyz/semantic-release/linux/amd64 -o ./semantic-release && chmod +x ./semantic-release

Plugin System

Since v2, semantic-release is equipped with a plugin system. The plugins are standalone binaries that use hashicorp/go-plugin as a plugin library.

semantic-release

automatically downloads the necessary plugins if they don't exist locally. The plugins are stored in the

.semrel

directory of the current working directory in the following format:

.semrel/_///

. The go-semantic-release plugins API (

https://plugins.go-semantic-release.xyz/api/v1/

) is used to resolve plugins to the correct binary. The served content of the API can be found here, and a list of all existing plugins can be found here.

Plugin Types

Commit Analyzer (Docs, Example)
CI Condition (Docs, Example)
Changelog Generator (Docs, Example)
Provider (Docs, Example)
Files Updater (Docs, Example)
Hooks (Docs)

Configuration

Plugins can be configured using CLI flags or the

.semrelrc

config file. By using a

sign after the plugin name, the required version of the plugin can be specified. Otherwise, any locally installed version will be used. If the plugin does not exist locally, the latest version will be downloaded. This is an example of the

.semrelrc

config file:

{
  "plugins": {
    "commit-analyzer": {
      "name": "[email protected]^1.0.0"
    },
    "ci-condition": {
      "name": "default"
    },
    "changelog-generator": {
      "name": "default",
      "options": {
        "emojis": "true"
      }
    },
    "provider": {
      "name": "gitlab",
      "options": {
        "gitlab_projectid": "123456"
      }
    },
    "files-updater": {
      "name": "npm"
    }
  }
}

Example GitHub Actions

For examples, look at the go-semantic-release GitHub Action.

Example GitLab CI Config

GitLab token

It is necessary to create a new Gitlab personal access token with the

api

scope here. Ensure the CI variable is protected and masked as the

GITLAB_TOKEN

has a lot of rights. There is an open issue for project specific tokens You can set the GitLab token via the

GITLAB_TOKEN

environment variable or the

-token

flag.

.gitlab-ci.yml ```yml stages: # other stages - release

release: image: registry.gitlab.com/go-semantic-release/semantic-release:latest # Replace this with the current release stage: release # Remove this if you want a release created for each push to master when: manual only: - master script: - release ```

Beta release support

Beta release support empowers you to release beta, rc, etc. versions with

semantic-release

(e.g. v2.0.0-beta.1). To enable this feature you need to create a new branch (e.g. beta/v2) and check in a

.semrelrc

file with the following content:

{
  "maintainedVersion": "2-beta"
}

If you commit to this branch a new incremental pre-release is created everytime you push. (2.0.0-beta.1, 2.0.0-beta.2, ...)

Licence

The MIT License (MIT)