Skip to content
Snippets Groups Projects
Select Git revision
  • 456245aabe465529d6623dafd8aa32ed152f5365
  • main default protected
  • fix/36615b-branch-reuse-no-cache
  • renovate/main-redis-5.x
  • next
  • revert-31645-feat/rename-gradle-wrapper-validation-action
  • chore/punycode
  • refactor/pin-new-value
  • feat/36219--git-x509-signing
  • feat/structured-logger
  • hotfix/39.264.1
  • feat/skip-dangling
  • gh-readonly-queue/next/pr-36034-7a061c4ca1024a19e2c295d773d9642625d1c2be
  • hotfix/39.238.3
  • refactor/gitlab-auto-approve
  • feat/template-strings
  • gh-readonly-queue/next/pr-35654-137d934242c784e0c45d4b957362214f0eade1d7
  • fix/32307-global-extends-merging
  • fix/32307-global-extends-repositories
  • gh-readonly-queue/next/pr-35009-046ebf7cb84ab859f7fefceb5fa53a54ce9736f8
  • gh-readonly-queue/next/pr-35009-9d5e583b7d7251148ab0d11ee8dd38149618d162
  • 41.38.2
  • 41.38.1
  • 41.38.0
  • 41.37.12
  • 41.37.11
  • 41.37.10
  • 41.37.9
  • 41.37.8
  • 41.37.7
  • 41.37.6
  • 41.37.5
  • 41.37.4
  • 41.37.3
  • 41.37.2
  • 41.37.1
  • 41.37.0
  • 41.36.2
  • 41.36.1
  • 41.36.0
  • 41.35.2
41 results

index.ts

Blame
  • README.md 6.51 KiB

    :package::rocket: semantic-release

    CI pipeline status Go Report Card PkgGoDev

    fully automated package/module/image publishing

    A more lightweight and standalone version of semantic-release.

    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/<os>_<arch>/<plugin name>/<version>/. 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

    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": "default@^1.0.0"
        },
        "ci-condition": {
          "name": "default"
        },
        "changelog-generator": {
          "name": "default",
          "options": {
            "emojis": "true"
          }
        },
        "provider": {
          "name": "gitlab",
          "options": {
            "gitlab_projectid": "123456"
          }
        },
        "files-updater": {
          "names": ["npm"]
        }
      }
    }