semantic-release/gitlab

:fox_face: semantic-release plugin to publish a GitLab release

📦🚀 semantic-release

Fully automated version management and package publishing

semantic-release automates the whole package release workflow including: determining the next version number, generating the release notes, and publishing the package.

This removes the immediate connection between human emotions and version numbers, strictly following the Semantic Versioning specification and communicating the impact of changes to consumers.

Trust us, this will change your workflow for the better. – egghead.io

Highlights

• Fully automated release
• Enforce Semantic Versioning specification
• New features and fixes are immediately available to users
• Notify maintainers and users of new releases
• Use formalized commit message convention to document changes in the codebase
• Publish on different distribution channels (such as npm dist-tags) based on git merges
• Integrate with your continuous integration workflow
• Avoid potential errors associated with manual releases
• Support any package managers and languages via plugins
• Simple and reusable configuration via shareable configurations
• Support for npm package provenance that promotes increased supply-chain security via signed attestations on GitHub Actions

How does it work?

Commit message format

semantic-release uses the commit messages to determine the consumer impact of changes in the codebase. Following formalized conventions for commit messages, semantic-release automatically determines the next semantic version number, generates a changelog and publishes the release.

By default, semantic-release uses Angular Commit Message Conventions. The commit message format can be changed with the preset or config options of the @semantic-release/commit-analyzer and @semantic-release/release-notes-generator plugins.

Tools such as commitizen or commitlint can be used to help contributors and enforce valid commit messages.

The table below shows which commit message gets you which release type when semantic-release runs (using the default configuration):

Commit message	Release type
fix(pencil): stop graphite breaking when too much pressure applied	Patch Fix Release
feat(pencil): add 'graphiteWidth' option	Minor Feature Release
perf(pencil): remove graphiteWidth option BREAKING CHANGE: The graphiteWidth option has been removed. The default graphite width of 10mm is always used for performance reasons.	Major Breaking Release (Note that the BREAKING CHANGE: token must be in the footer of the commit)

Automation with CI

semantic-release is meant to be executed on the CI environment after every successful build on the release branch. This way no human is directly involved in the release process and the releases are guaranteed to be unromantic and unsentimental.

Triggering a release

For each new commit added to one of the release branches (for example: master, next, beta), with git push or by merging a pull request or merging from another branch, a CI build is triggered and runs the semantic-release command to make a release if there are codebase changes since the last release that affect the package functionalities.

semantic-release offers various ways to control the timing, the content and the audience of published releases. See example workflows in the following recipes:

• Using distribution channels
• Maintenance releases
• Pre-releases

Release steps

After running the tests, the command semantic-release will execute the following steps:

Step	Description
Verify Conditions	Verify all the conditions to proceed with the release.
Get last release	Obtain the commit corresponding to the last release by analyzing Git tags.
Analyze commits	Determine the type of release based on the commits added since the last release.
Verify release	Verify the release conformity.
Generate notes	Generate release notes for the commits added since the last release.
Create Git tag	Create a Git tag corresponding to the new release version.
Prepare	Prepare the release.
Publish	Publish the release.
Notify	Notify of new releases or errors.

Requirements

In order to use semantic-release you need:

• To host your code in a Git repository
• Use a Continuous Integration service that allows you to securely set up credentials
• A Git CLI version that meets our version requirement installed in your Continuous Integration environment
• A Node.js version that meets our version requirement installed in your Continuous Integration environment

Documentation

• Usage
  • Getting started
  • Installation
  • CI Configuration
  • Configuration
  • Plugins
  • Workflow configuration
  • Shareable configurations
• Extending
  • Plugins
  • Shareable configuration
• Recipes
  • CI configurations
  • Git hosted services
  • Release workflow
• Developer guide
  • JavaScript API
  • Plugins development
  • Shareable configuration development
• Support
  • Resources
  • Frequently Asked Questions
  • Troubleshooting
  • Node version requirement
  • Node Support Policy

Get help

• GitHub Discussions
• Stack Overflow
• Twitter

Badge

Let people know that your package is published using semantic-release and which commit-convention is followed by including this badge in your readme.

[![semantic-release: angular](https://img.shields.io/badge/semantic--release-angular-e10079?logo=semantic-release)](https://github.com/semantic-release/semantic-release)

Team

Gregor Martynus	Pierre Vanduynslager	Matt Travi

Alumni

Stephan Bönnemann	Rolf Erik Lekang	Johannes Jörg Schmidt	Finn Pauls	Christoph Witzko

gitlab's Issues

How to bundle assets to a label.zip

Is it possible to keep folder structure and bundle to a zip like following:

"@semantic-release/gitlab",
{
    "assets": [
        { paths: ["dist/**/*"], label: "dist.zip" }
    ]
}

409 Conflict error while posting release

Hi! I've been using this library for a long time with different providers (github, gitlab, bitbucket) and it was working always good.

However on one of my projects on gitlab I stated to face errors 409 Conflict while posting a release for tags on master.

First I want to explain the model of releases that I'm using there to give you the context.

I have 2 main branches: master and develop.
Releases happen from both branches with different tag names:

• v${version} on master
• v${version}-dev on develop
  This is done to simulate pre-peleases since this feature is still in beta.

Now everything on develop is working great. But when I merge to master release with tag is created but gitlab responds with 409 Conflict and that fails the pipeline.

I think that there is something wrong with Gitlab API but before going to them I wanted to first ask here if it is not the problem of semantic release gitlab plugin by any chance.

Here is the log with `--debug` flag

[14:19:01] [semantic-release] › ℹ  Running semantic-release version 15.13.3
2019-02-04T14:19:01.530Z semantic-release:config load config from: /project/xxx/.releaserc
2019-02-04T14:19:01.556Z semantic-release:config options values: { branch: 'master',
  repositoryUrl: 'https://gitlab-ci-token:[secure]@xxx.com/project/xxx.git',
  tagFormat: 'v${version}',
  plugins: 
   [ '@semantic-release/commit-analyzer',
     '@semantic-release/release-notes-generator',
     [ '@semantic-release/changelog', [Object] ],
     [ '@semantic-release/npm', [Object] ],
     [ '@semantic-release/exec', [Object] ],
     [ '@semantic-release/git', [Object] ],
     [ '@semantic-release/gitlab', [Object] ] ],
  _: [],
  b: 'master',
  debug: true,
  '$0': 'node_modules/.bin/semantic-release' }
2019-02-04T14:19:06.014Z semantic-release:plugins options for @semantic-release/changelog/verifyConditions: { changelogFile: 'CHANGELOG.md',
  changelogTitle: '# Immoforce - Changelog' }
2019-02-04T14:19:06.016Z semantic-release:plugins options for @semantic-release/npm/verifyConditions: { npmPublish: false }
[14:19:06] [semantic-release] › ✔  Loaded plugin "verifyConditions" from "@semantic-release/changelog"
2019-02-04T14:19:06.017Z semantic-release:plugins options for @semantic-release/exec/verifyConditions: { verifyReleaseCmd: './scripts/release-verify.sh "${nextRelease.gitTag}"',
  prepareCmd: './scripts/release-prepare.sh "${nextRelease.gitTag}"' }
[14:19:06] [semantic-release] › ✔  Loaded plugin "verifyConditions" from "@semantic-release/npm"
[14:19:06] [semantic-release] › ✔  Loaded plugin "verifyConditions" from "@semantic-release/exec"
2019-02-04T14:19:06.018Z semantic-release:plugins options for @semantic-release/git/verifyConditions: { assets: [ 'CHANGELOG.md', 'package.json' ],
  message: 'chore(release): update version ${nextRelease.gitTag} [skip ci]' }
[14:19:06] [semantic-release] › ✔  Loaded plugin "verifyConditions" from "@semantic-release/git"
2019-02-04T14:19:06.019Z semantic-release:plugins options for @semantic-release/gitlab/verifyConditions: { gitlabUrl: 'https://xxx.com' }
[14:19:06] [semantic-release] › ✔  Loaded plugin "verifyConditions" from "@semantic-release/gitlab"
2019-02-04T14:19:06.020Z semantic-release:plugins options for @semantic-release/commit-analyzer/analyzeCommits: {}
[14:19:06] [semantic-release] › ✔  Loaded plugin "analyzeCommits" from "@semantic-release/commit-analyzer"
[14:19:06] [semantic-release] › ✔  Loaded plugin "analyzeCommits" from "@semantic-release/exec"
2019-02-04T14:19:06.020Z semantic-release:plugins options for @semantic-release/exec/analyzeCommits: { verifyReleaseCmd: './scripts/release-verify.sh "${nextRelease.gitTag}"',
  prepareCmd: './scripts/release-prepare.sh "${nextRelease.gitTag}"' }
2019-02-04T14:19:06.021Z semantic-release:plugins options for @semantic-release/exec/verifyRelease: { verifyReleaseCmd: './scripts/release-verify.sh "${nextRelease.gitTag}"',
  prepareCmd: './scripts/release-prepare.sh "${nextRelease.gitTag}"' }
2019-02-04T14:19:06.021Z semantic-release:plugins options for @semantic-release/release-notes-generator/generateNotes: {}
[14:19:06] [semantic-release] › ✔  Loaded plugin "verifyRelease" from "@semantic-release/exec"
[14:19:06] [semantic-release] › ✔  Loaded plugin "generateNotes" from "@semantic-release/release-notes-generator"
[14:19:06] [semantic-release] › ✔  Loaded plugin "generateNotes" from "@semantic-release/exec"
2019-02-04T14:19:06.022Z semantic-release:plugins options for @semantic-release/exec/generateNotes: { verifyReleaseCmd: './scripts/release-verify.sh "${nextRelease.gitTag}"',
  prepareCmd: './scripts/release-prepare.sh "${nextRelease.gitTag}"' }
[14:19:06] [semantic-release] › ✔  Loaded plugin "prepare" from "@semantic-release/changelog"
2019-02-04T14:19:06.022Z semantic-release:plugins options for @semantic-release/changelog/prepare: { changelogFile: 'CHANGELOG.md',
  changelogTitle: '# Immoforce - Changelog' }
[14:19:06] [semantic-release] › ✔  Loaded plugin "prepare" from "@semantic-release/npm"
2019-02-04T14:19:06.023Z semantic-release:plugins options for @semantic-release/npm/prepare: { npmPublish: false }
2019-02-04T14:19:06.023Z semantic-release:plugins options for @semantic-release/exec/prepare: { verifyReleaseCmd: './scripts/release-verify.sh "${nextRelease.gitTag}"',
  prepareCmd: './scripts/release-prepare.sh "${nextRelease.gitTag}"' }
[14:19:06] [semantic-release] › ✔  Loaded plugin "prepare" from "@semantic-release/exec"
2019-02-04T14:19:06.024Z semantic-release:plugins options for @semantic-release/git/prepare: { assets: [ 'CHANGELOG.md', 'package.json' ],
  message: 'chore(release): update version ${nextRelease.gitTag} [skip ci]' }
[14:19:06] [semantic-release] › ✔  Loaded plugin "prepare" from "@semantic-release/git"
2019-02-04T14:19:06.025Z semantic-release:plugins options for @semantic-release/npm/publish: { npmPublish: false }
[14:19:06] [semantic-release] › ✔  Loaded plugin "publish" from "@semantic-release/npm"
2019-02-04T14:19:06.025Z semantic-release:plugins options for @semantic-release/exec/publish: { verifyReleaseCmd: './scripts/release-verify.sh "${nextRelease.gitTag}"',
  prepareCmd: './scripts/release-prepare.sh "${nextRelease.gitTag}"' }
[14:19:06] [semantic-release] › ✔  Loaded plugin "publish" from "@semantic-release/exec"
2019-02-04T14:19:06.026Z semantic-release:plugins options for @semantic-release/gitlab/publish: { gitlabUrl: 'https://xxx.com' }
[14:19:06] [semantic-release] › ✔  Loaded plugin "publish" from "@semantic-release/gitlab"
[14:19:06] [semantic-release] › ✔  Loaded plugin "success" from "@semantic-release/exec"
2019-02-04T14:19:06.026Z semantic-release:plugins options for @semantic-release/exec/success: { verifyReleaseCmd: './scripts/release-verify.sh "${nextRelease.gitTag}"',
  prepareCmd: './scripts/release-prepare.sh "${nextRelease.gitTag}"' }
2019-02-04T14:19:06.027Z semantic-release:plugins options for @semantic-release/exec/fail: { verifyReleaseCmd: './scripts/release-verify.sh "${nextRelease.gitTag}"',
  prepareCmd: './scripts/release-prepare.sh "${nextRelease.gitTag}"' }
[14:19:06] [semantic-release] › ✔  Loaded plugin "fail" from "@semantic-release/exec"
[14:19:06] [semantic-release] › ✔  Run automated release from branch master
2019-02-04T14:19:06.993Z semantic-release:git Error: Command failed: git push --dry-run https://gitlab-ci-token:[secure]@xxx.com/project/xxx.git HEAD:master
remote: You are not allowed to upload code.
fatal: unable to access 'https://gitlab-ci-token:[secure]@xxx.com/project/xxx.git/': The requested URL returned error: 403


    at makeError (/project/xxx/node_modules/execa/index.js:174:9)
    at Promise.all.then.arr (/project/xxx/node_modules/execa/index.js:278:16)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:188:7)
[14:19:07] [semantic-release] › ✔  Allowed to push to the Git repository
[14:19:07] [semantic-release] › ℹ  Start step "verifyConditions" of plugin "@semantic-release/changelog"
[14:19:07] [semantic-release] › ✔  Completed step "verifyConditions" of plugin "@semantic-release/changelog"
[14:19:07] [semantic-release] › ℹ  Start step "verifyConditions" of plugin "@semantic-release/npm"
[14:19:07] [semantic-release] › ✔  Completed step "verifyConditions" of plugin "@semantic-release/npm"
[14:19:07] [semantic-release] › ℹ  Start step "verifyConditions" of plugin "@semantic-release/exec"
[14:19:07] [semantic-release] › ✔  Completed step "verifyConditions" of plugin "@semantic-release/exec"
[14:19:07] [semantic-release] › ℹ  Start step "verifyConditions" of plugin "@semantic-release/git"
[14:19:07] [semantic-release] › ✔  Completed step "verifyConditions" of plugin "@semantic-release/git"
[14:19:07] [semantic-release] › ℹ  Start step "verifyConditions" of plugin "@semantic-release/gitlab"
2019-02-04T14:19:07.364Z semantic-release:gitlab repoId: 'project/xxx'
2019-02-04T14:19:07.365Z semantic-release:gitlab apiUrl: 'https://xxx.com/api/v4'
[14:19:07] [semantic-release] [@semantic-release/gitlab] › ℹ  Verify GitLab authentication (https://xxx.com/api/v4)
[14:19:07] [semantic-release] › ✔  Completed step "verifyConditions" of plugin "@semantic-release/gitlab"
2019-02-04T14:19:08.116Z semantic-release:get-last-release found tags: []
[14:19:08] [semantic-release] › ℹ  No git tag version found
[14:19:08] [semantic-release] › ℹ  No previous release found, retrieving all commits
[14:19:08] [semantic-release] › ℹ  Found 5706 commits since last release
2019-02-04T14:19:08.626Z semantic-release:get-commits Parsed commits: [...]
[14:19:08] [semantic-release] › ℹ  Start step "analyzeCommits" of plugin "@semantic-release/commit-analyzer"
[14:19:10] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  Analyzing commit: ci(gitlab): run release in debug mode
...
[14:19:10] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  The release type for the commit is major
2019-02-04T14:19:10.586Z semantic-release:commit-analyzer Analyzing with default rules
2019-02-04T14:19:10.586Z semantic-release:commit-analyzer The rule { breaking: true, release: 'major' } match commit with release type 'major'
2019-02-04T14:19:10.586Z semantic-release:commit-analyzer Release type 'major' is the highest possible. Stop analysis.
[14:19:10] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  Analysis of 5706 commits complete: major release
[14:19:10] [semantic-release] › ✔  Completed step "analyzeCommits" of plugin "@semantic-release/commit-analyzer"
[14:19:10] [semantic-release] › ℹ  Start step "analyzeCommits" of plugin "@semantic-release/exec"
[14:19:10] [semantic-release] › ✔  Completed step "analyzeCommits" of plugin "@semantic-release/exec"
[14:19:10] [semantic-release] › ℹ  There is no previous release, the next release version is 1.0.0
[14:19:10] [semantic-release] › ℹ  Start step "verifyRelease" of plugin "@semantic-release/exec"
[14:19:10] [semantic-release] [@semantic-release/exec] › ℹ  Call script ./scripts/release-verify.sh "v1.0.0"
Running sonarqube testing on version v1.0.0 in publish mode!
[14:20:43] [semantic-release] › ✔  Completed step "verifyRelease" of plugin "@semantic-release/exec"
[14:20:43] [semantic-release] › ℹ  Start step "generateNotes" of plugin "@semantic-release/release-notes-generator"
2019-02-04T14:20:45.370Z semantic-release:release-notes-generator version: '1.0.0'
2019-02-04T14:20:45.370Z semantic-release:release-notes-generator host: 'xxx.com'
2019-02-04T14:20:45.370Z semantic-release:release-notes-generator owner: 'angularjs'
2019-02-04T14:20:45.371Z semantic-release:release-notes-generator repository: 'project-xxx'
2019-02-04T14:20:45.371Z semantic-release:release-notes-generator previousTag: undefined
2019-02-04T14:20:45.371Z semantic-release:release-notes-generator currentTag: 'v1.0.0'
[14:20:46] [semantic-release] › ✔  Completed step "generateNotes" of plugin "@semantic-release/release-notes-generator"
[14:20:46] [semantic-release] › ℹ  Start step "generateNotes" of plugin "@semantic-release/exec"
[14:20:46] [semantic-release] › ✔  Completed step "generateNotes" of plugin "@semantic-release/exec"
[14:20:46] [semantic-release] › ℹ  Start step "prepare" of plugin "@semantic-release/changelog"
[14:20:46] [semantic-release] [@semantic-release/changelog] › ℹ  Update /project/xxx/CHANGELOG.md
[14:20:46] [semantic-release] › ✔  Completed step "prepare" of plugin "@semantic-release/changelog"
[14:20:46] [semantic-release] › ℹ  Start step "prepare" of plugin "@semantic-release/npm"
[14:20:46] [semantic-release] [@semantic-release/npm] › ℹ  Write version 1.0.0 to package.json in /project/xxx
v1.0.0
[14:20:47] [semantic-release] › ✔  Completed step "prepare" of plugin "@semantic-release/npm"
[14:20:47] [semantic-release] › ℹ  Start step "prepare" of plugin "@semantic-release/exec"
[14:20:47] [semantic-release] [@semantic-release/exec] › ℹ  Call script ./scripts/release-prepare.sh "v1.0.0"
Writing version `1.0.0` into file ./src/generated/version.ts
[14:20:47] [semantic-release] › ✔  Completed step "prepare" of plugin "@semantic-release/exec"
[14:20:47] [semantic-release] › ℹ  Start step "prepare" of plugin "@semantic-release/git"
2019-02-04T14:20:47.925Z semantic-release:git globed assets: [ 'CHANGELOG.md', 'package.json' ]
[14:20:47] [semantic-release] [@semantic-release/git] › ℹ  Found 2 file(s) to commit
2019-02-04T14:20:48.003Z semantic-release:git add file to git index { stdout: '',
  stderr: '',
  code: 0,
  failed: false,
  killed: false,
  signal: null,
  cmd: 'git add --force --ignore-errors CHANGELOG.md package.json',
  timedOut: false }
2019-02-04T14:20:48.004Z semantic-release:git commited files: [ 'CHANGELOG.md', 'package.json' ]
[14:20:49] [semantic-release] [@semantic-release/git] › ℹ  Prepared Git release: v1.0.0
[14:20:49] [semantic-release] › ✔  Completed step "prepare" of plugin "@semantic-release/git"
[14:20:49] [semantic-release] › ℹ  Start step "generateNotes" of plugin "@semantic-release/release-notes-generator"
2019-02-04T14:20:51.387Z semantic-release:release-notes-generator version: '1.0.0'
2019-02-04T14:20:51.388Z semantic-release:release-notes-generator host: 'xxx.com'
2019-02-04T14:20:51.388Z semantic-release:release-notes-generator owner: 'angularjs'
2019-02-04T14:20:51.388Z semantic-release:release-notes-generator repository: 'project-xxx'
2019-02-04T14:20:51.388Z semantic-release:release-notes-generator previousTag: undefined
2019-02-04T14:20:51.388Z semantic-release:release-notes-generator currentTag: 'v1.0.0'
[14:20:52] [semantic-release] › ✔  Completed step "generateNotes" of plugin "@semantic-release/release-notes-generator"
[14:20:52] [semantic-release] › ℹ  Start step "generateNotes" of plugin "@semantic-release/exec"
[14:20:52] [semantic-release] › ✔  Completed step "generateNotes" of plugin "@semantic-release/exec"
[14:20:53] [semantic-release] › ✔  Created tag v1.0.0
[14:20:53] [semantic-release] › ℹ  Start step "publish" of plugin "@semantic-release/npm"
[14:20:53] [semantic-release] [@semantic-release/npm] › ℹ  Skip publishing to npm registry as npmPublish is false
[14:20:53] [semantic-release] › ✔  Completed step "publish" of plugin "@semantic-release/npm"
[14:20:53] [semantic-release] › ℹ  Start step "publish" of plugin "@semantic-release/exec"
[14:20:53] [semantic-release] › ✔  Completed step "publish" of plugin "@semantic-release/exec"
[14:20:53] [semantic-release] › ℹ  Start step "publish" of plugin "@semantic-release/gitlab"
2019-02-04T14:20:53.948Z semantic-release:gitlab repoId: 'project/xxx'
2019-02-04T14:20:53.948Z semantic-release:gitlab release name: 'v1.0.0'
2019-02-04T14:20:53.948Z semantic-release:gitlab release ref: 'c121389491e42e02a3be4c38b3768120f1767ac6'
2019-02-04T14:20:53.948Z semantic-release:gitlab Update git tag 'v1.0.0' with commit 'c121389491e42e02a3be4c38b3768120f1767ac6' and release description
[14:20:54] [semantic-release] › ✖  Failed step "publish" of plugin "@semantic-release/gitlab"
[14:20:54] [semantic-release] › ✖  An error occurred while running semantic-release: { HTTPError: Response code 409 (Conflict)
    at EventEmitter.emitter.on (/project/xxx/node_modules/got/source/as-promise.js:74:19)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:188:7)
  name: 'HTTPError',
  host: 'xxx.com',
  hostname: 'xxx.com',
  method: 'POST',
  path: '/api/v4/projects/project-xxx/repository/tags/v1.0.0/release',
  socketPath: undefined,
  protocol: 'https:',
  url: 'https://xxx.com/api/v4/projects/project-xxx/repository/tags/v1.0.0/release',
  gotOptions: 
   { path: '/api/v4/projects/project-xxx/repository/tags/v1.0.0/release',
     protocol: 'https:',
     slashes: true,
     auth: null,
     host: 'xxx.com',
     port: null,
     hostname: 'xxx.com',
     hash: null,
     search: null,
     query: null,
     pathname: '/api/v4/projects/project-xxx/repository/tags/v1.0.0/release',
     href: 'https://xxx.com/api/v4/projects/project-xxx/repository/tags/v1.0.0/release',
     retry: 
      { retries: [Function],
        methods: [Object],
        statusCodes: [Object],
        errorCodes: [Object] },
     headers: 
      { 'user-agent': 'got/9.6.0 (https://github.com/sindresorhus/got)',
        'private-token': '[secure]',
        accept: 'application/json',
        'accept-encoding': 'gzip, deflate',
        'content-type': 'application/json',
        'content-length': 121463 },
     hooks: 
      { beforeRequest: [],
        beforeRedirect: [],
        beforeRetry: [],
        afterResponse: [],
        beforeError: [],
        init: [] },
     decompress: true,
     throwHttpErrors: true,
     followRedirect: true,
     stream: false,
     form: false,
     json: true,
     cache: false,
     useElectronNet: false,
     body: "...",
     method: 'POST' },
  statusCode: 409,
  statusMessage: 'Conflict',
  headers: 
   { server: 'nginx',
     date: 'Mon, 04 Feb 2019 14:20:54 GMT',
     'content-type': 'application/json',
     'content-length': '36',
     connection: 'close',
     'cache-control': 'no-cache',
     vary: 'Origin',
     'x-content-type-options': 'nosniff',
     'x-frame-options': 'SAMEORIGIN',
     'x-request-id': '2c2fff65-dcd2-4bfa-9271-c5a438f7fd11',
     'x-runtime': '0.070336' },
  body: { message: 'Release already exists' },
  pluginName: '@semantic-release/gitlab' }

  ERROR: Job failed: command terminated with exit code 1

Encode git tag in publish release notes URI

Hey all,

Apologies for the sloppiness of this PR, doing this in a meeting: #25

I couldn't get @semantic-release/gitlab to publish correctly from our lerna monorepo for shared modules.

I found the issue was with the git tags having a / in them that wasn't URI encoded and as such, causing a 404.

Hopefully what I've done is good enough to merge. 🙂

Thanks,
Christos.

400 Error when publishing

As title suggests I'm getting a 400 error when publishing to gitlab. I think this is due to
body: {tag_name: gitTag, ref: gitHead, release_description: notes}, // eslint-disable-line camelcase in publish.js

I think this is submitting the incorrect payload. As outlined in the gitlab docs:

• id (required) - The ID or URL-encoded path of the project owned by the authenticated user
• tag_name (required) - The name of a tag
• description (required) - Release notes with markdown support`

Is this the case or am I totally off? Happy to do a PR for this if I am correct - just wanted to know if I was correct in my guess.
Thanks for the plugin! :D

Order of release assets is scrambled

I just started using this plugin to create gitlab releases, but I see that the assets on the release page are in a scrambled order?

My plugin is set up like this:

    ["@semantic-release/gitlab", {
      "assets": [
        {"path": "CHANGELOG.md", "label": "Changelog"},
        ['dist/*.tar.gz','dist/*.zip', "dist/*SHA256SUMS"],
      ]
    }],

The order of the assets on the release however end up something like this:

myrelease_1.0.0_darwin_x86_64.tar.gz
myrelease_1.0.0_linux_arm64.tar.gz
myrelease_1.0.0_linux_i386.tar.gz
myrelease_1.0.0_linux_x86_64.tar.gz
myrelease_1.0.0_SHA256SUMS
Changelog
myrelease_1.0.0_windows_i386.zip
myrelease_1.0.0_windows_x86_64.zip

Is there a way to define the order that the assets land on the release page?
I would understand if the globbed assets are in random order, but why is the changelog randomly in the middle there?

Authentication fails

Trying to implement semantic-release for Gitlab. I have a non-traditional setup with the original repository in Github that is mirrored to Gitlab. CI job runs on Gitlab.
The Gitlab token is defined in variables and I tested from command line that it works.
I think the issue is in the url "https://[secure]@gitlab.com". There should be a username.

Possibly the script tries to connect to Gitlab but uses Github syntax for URL?
Ideally I would like to publish to both.

[2:33:43 PM] [semantic-release] » × An error occurred while running semantic-release: Error: Command failed with exit code 128: git ls-remote --heads https://[secure]@gitlab.com/******/Release_test.git
Logon failed, use ctrl+c to cancel basic credential prompt.
remote: HTTP Basic: Access denied
fatal: Authentication failed for 'https://gitlab.com/*****/Release_test.git/'

Support `CI_JOB_TOKEN` auth

GitLab CI injects CI_JOB_TOKEN to allow a pipeline job to access a project resource through public v4 API. Not all of APIs support job token auth, however, release creation API is already supported. So in theory, executing GITLAB_TOKEN=$CI_JOB_TOKEN should be suffice to run semantic-release.

However, as I tested https://gitlab.com/dosuken123/semantic-release-test/-/jobs/628942282, it didn't succeed as semantic-release tried remote Git repository authentication. I'm not sure why it's necessary as the tag creation is done via the above API call.

If CI_JOB_TOKEN auth is possible, it's very convenient to run semantic-release in GitLab CI as users don't need to create PAT.

Assets on release tag

Similar to semantic-release/github, it would be awesome if the gitlab package add a assets on the release notes: see this API endpoint https://docs.gitlab.com/ce/api/projects.html#upload-a-file

Commit files with updated version number with tag

In many cases, a hard coded version number is included in the code that needs to be updated when a new version is released. It would be nice if we could optionally create a commit with those files in it and tag that, instead of tagging the current commit.

Gitlab's api supports this - https://docs.gitlab.com/ee/api/commits.html

Cannot upload assets

Hi all,

I'm having an issue with uploading assets along with my release.
It seems to find the files fine but is unable to finalize the publish step, giving no errors or indication why it is failing.
The gitlab-CI pipeline indicates that it has run fine but no release is created.
The last debug log that can be seen from the gitlab-runner is:

 2020-04-10T21:22:30.883Z semantic-release:gitlab file path: 'CHANGELOG.md'
 2020-04-10T21:22:30.884Z semantic-release:gitlab file label: 'official release files'

Here is my plugin config:

plugins:
  - "@semantic-release/commit-analyzer"
  - "@semantic-release/release-notes-generator"
  - - "@semantic-release/changelog"
    - changelogTitle: "# CHANGELOG"
  - "@semantic-release/git"
  - - "@semantic-release/gitlab"
    - assets: [{"path": "*.md", "label": "official release files"}]

When the assets object is removed from the config the plugin works fine.

Any clues and ideas are much appreciated!

Thank you

Understanding inconsistent behavior across github, gitlab, and git plugins

It's a bit strange that @semantic-release/gitlab will tag a commit and create a gitlab release, but it doesn't do the other features that @semantic-release/git will do, such as committing changed files with a specified commit message.

If I remember correctly, @semantic-release/github creates a github release, but does NOT tag a commit. You are relegated to using the git plugin for tagging.

Since tagging is part of the contents of the git repo, and not a property of the repository hosting, shouldn't the behavior be consistent? If making changes to the git repo is part of the repository hosting process, then shouldn't all the features of git be supported (or encapsulated) in the repo hosting plugin as well?

EMISSINGREPO thrown when in fact the reverse proxy in front of GitLab is incorrectly configured

See toward the end of #63 (comment).

Verification currently does not make a distinction when the repository is really missing (response with statusCode at 404 and statusMessage is Project Not Found) and when there is a problem with a badly configured reverse-proxy (same but statusMessage is Not Found).

Test suite improvements

Problems like #92 where not caught by the unit tests. They need to be improved.

Gitlab environment variables not populating correctly for private instances

#115 introduced the ability to automatically retrieve Gitlab to fix #114

But it doesn't appear to be working correctly. I removed GITLAB_PREFIX and GITLAB_URL so that they could be automatically determined from the Gitlab runner-provided environment variables CI_API_V4_URL

When I look at the error log, I can see that @semantic-release/gitlab reverted to using the public gitlab.com and not the private corporate gitlab server that is defined in CI_API_V4_URL, CI_PROJECT_URL, or CI_PROJECT_PATH.

In my runners, all 3 of those environment variables are defined with the private gitlab server URL, yet the public gitlab.com is what is being used:

[10:26:37 PM] [semantic-release] [@semantic-release/gitlab] › ℹ  Verify GitLab authentication (https://gitlab.com/api/v4)
[10:33:11 PM] [semantic-release] › ✖  Failed step "verifyConditions" of plugin "@semantic-release/gitlab"
[10:33:11 PM] [semantic-release] › ✖  An error occurred while running semantic-release: GotError [RequestError]: connect ETIMEDOUT 35.231.145.151:443
    at ClientRequest.<anonymous> (/builds/UI-TOOLS/create-usb-nextjs-app/node_modules/@semantic-release/gitlab/node_modules/got/source/request-as-event-emitter.js:178:14)
    at Object.onceWrapper (events.js:412:26)
    at ClientRequest.emit (events.js:317:22)
    at ClientRequest.origin.emit (/builds/UI-TOOLS/create-usb-nextjs-app/node_modules/@semantic-release/gitlab/node_modules/@szmarczak/http-timer/source/index.js:37:11)
    at TLSSocket.socketErrorListener (_http_client.js:423:9)
    at TLSSocket.emit (events.js:305:20)
    at emitErrorNT (internal/streams/destroy.js:84:8)
    at processTicksAndRejections (internal/process/task_queues.js:84:21) {
  name: 'RequestError',
  code: 'ETIMEDOUT',
  host: 'gitlab.com',
  hostname: 'gitlab.com',
  method: 'GET',
  path: '/api/v4/projects/UI-TOOLS%2Fcreate-usb-nextjs-app',
  socketPath: undefined,
  protocol: 'https:',
  url: 'https://gitlab.com/api/v4/projects/UI-TOOLS%2Fcreate-usb-nextjs-app',
  gotOptions: {
    path: '/api/v4/projects/UI-TOOLS%2Fcreate-usb-nextjs-app',
    protocol: 'https:',
    slashes: true,
    auth: null,
    host: 'gitlab.com',
    port: null,
    hostname: 'gitlab.com',
    hash: null,
    search: null,
    query: null,
    pathname: '/api/v4/projects/UI-TOOLS%2Fcreate-usb-nextjs-app',
    href: 'https://gitlab.com/api/v4/projects/UI-TOOLS%2Fcreate-usb-nextjs-app',
    retry: {
      retries: [Function (anonymous)],
      methods: [Set],
      statusCodes: [Set],
      errorCodes: [Set]
    },
    headers: {
      'user-agent': 'got/9.6.0 (https://github.com/sindresorhus/got)',
      'private-token': '[secure]',
      accept: 'application/json',
      'accept-encoding': 'gzip, deflate'
    },
    hooks: {
      beforeRequest: [],
      beforeRedirect: [],
      beforeRetry: [],
      afterResponse: [],
      beforeError: [],
      init: []
    },
    decompress: true,
    throwHttpErrors: true,
    followRedirect: true,
    stream: false,
    form: false,
    json: true,
    cache: false,
    useElectronNet: false,
    method: 'GET',
    forceRefresh: true
  },
  pluginName: '@semantic-release/gitlab'
}

I currently provide the repositoryUrl at runtime as a variable so that doesn't need to be explicitly defined in the build scripts: semantic-release --repository-url=$CI_REPOSITORY_URL. The only changes I made to take advantage of the new feature is to remove my previously defined GITLAB_PREFIX and GITLAB_URL environment variables and to bump which version of @semantic-release/gitlab I was using.

Validation failed: Description can\'t be blank

I am running:

docker run -e NPM_TOKEN=${NPM_TOKEN} -e GITLAB_TOKEN=${GITLAB_TOKEN} $CI_REGISTRY_IMAGE:$BUILD_TAG /bin/sh -c 'npm run build && semantic-release --no-ci'

and getting:

  body:
   { message: 'Validation failed: Description can\'t be blank' },
  pluginName: '@semantic-release/gitlab' }
{ HTTPError: Response code 400 (Bad Request)
    at EventEmitter.emitter.on (/srv/node_modules/got/source/as-promise.js:74:19)
    at process._tickCallback (internal/process/next_tick.js:68:7)

It is not clear what description the error is referring to.

Here is an example of another (public) project getting the same error:

https://git.happy-dev.fr/startinblox/devops/siblab-js/-/jobs/5312

An in-range update of got is breaking the build 🚨

The dependency got was updated from 10.5.0 to 10.5.1.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

got is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Status Details

• ❌ continuous-integration/travis-ci/push: The Travis CI build failed (Details).

---

Release Notes for v10.5.1

• Wait until body file descriptor is open (#1054) 453a3a3

v10.5.0...v10.5.1

Commits

The new version differs by 2 commits.

• 78fb85b 10.5.1
• 453a3a3 Wait until body file descriptor is open (#1054)

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴

Upcoming release config

Add ability to pass upcoming release state via releasedAt/upcoming config option:

{
  "plugins": [
    "@semantic-release/commit-analyzer",
    "@semantic-release/release-notes-generator",
    ["@semantic-release/gitlab", {
      "gitlabUrl": "https://custom.gitlab.com",
      "releasedAt": "SOME_TIMESTAMP_OR_ENV_VAR", // or "upcoming": true
      "assets": [
        {"path": "dist/asset.min.css", "label": "CSS distribution"},
        {"path": "dist/asset.min.js", "label": "JS distribution"}
      ]
    }],
  ]
}

Failed step "verifyConditions" of plugin "@semantic-release/gitlab"

Can't get passed "verifyConditions" with the @semantic-release/gitlab plugin.

$ npx semantic-release --debug
npx: installed 782 in 21.926s
[9:14:04 PM] [semantic-release] › ℹ  Running semantic-release version 15.13.3
2019-01-28T21:14:04.378Z semantic-release:config load config from: /builds/development/library/javascript/react-primitive-components/.releaserc.yml
2019-01-28T21:14:04.386Z semantic-release:config options values: { branch: 'master',
  repositoryUrl:
   '[email protected]:development/library/javascript/react-primitive-components.git',
  tagFormat: 'v${version}',
  plugins:
   [ '@semantic-release/commit-analyzer',
     '@semantic-release/release-notes-generator',
     [ '@semantic-release/gitlab', [Object] ] ],
  release: { branch: 'master' },
  _: [],
  debug: true,
  '$0': '/root/.npm/_npx/17/bin/semantic-release' }
2019-01-28T21:14:04.783Z semantic-release:plugins options for @semantic-release/gitlab/verifyConditions: { gitlabUrl: 'https://gitlabdev.paciolan.info',
  verifyConditions: [],
  assets: [ { path: [Array], label: 'JS distribution' } ] }
[9:14:04 PM] [semantic-release] › ✔  Loaded plugin "verifyConditions" from "@semantic-release/gitlab"
2019-01-28T21:14:04.786Z semantic-release:plugins options for @semantic-release/commit-analyzer/analyzeCommits: {}
[9:14:04 PM] [semantic-release] › ✔  Loaded plugin "analyzeCommits" from "@semantic-release/commit-analyzer"
2019-01-28T21:14:04.786Z semantic-release:plugins options for @semantic-release/release-notes-generator/generateNotes: {}
[9:14:04 PM] [semantic-release] › ✔  Loaded plugin "generateNotes" from "@semantic-release/release-notes-generator"
2019-01-28T21:14:04.787Z semantic-release:plugins options for @semantic-release/gitlab/publish: { gitlabUrl: 'https://gitlabdev.paciolan.info',
  verifyConditions: [],
  assets: [ { path: [Array], label: 'JS distribution' } ] }
[9:14:04 PM] [semantic-release] › ✔  Loaded plugin "publish" from "@semantic-release/gitlab"
[9:14:04 PM] [semantic-release] › ✔  Run automated release from branch master
[9:14:06 PM] [semantic-release] › ✔  Allowed to push to the Git repository
[9:14:06 PM] [semantic-release] › ℹ  Start step "verifyConditions" of plugin "@semantic-release/gitlab"
2019-01-28T21:14:06.700Z semantic-release:gitlab repoId: 'development/library/javascript/react-primitive-components'
2019-01-28T21:14:06.702Z semantic-release:gitlab apiUrl: 'https://gitlabdev.paciolan.info/api/v4'
[9:14:06 PM] [semantic-release] [@semantic-release/gitlab] › ℹ  Verify GitLab authentication (https://gitlabdev.paciolan.info/api/v4)
[9:14:06 PM] [semantic-release] › ✖  Failed step "verifyConditions" of plugin "@semantic-release/gitlab"
[9:14:06 PM] [semantic-release] › ✖  EGLNOPERMISSION The GitLab token doesn't allow to push on the repository development/library/javascript/react-primitive-components.
The user associated with the GitLab token (https://github.com/semantic-release/gitlab/blob/master/README.md#gitlab-authentication) configured in the GL_TOKEN or GITLAB_TOKEN environment variable must allows to push to the repository development/library/javascript/react-primitive-components.

Please make sure the GitLab user associated with the token has the permission to push (https://docs.gitlab.com/ee/user/permissions.html#project-members-permissions) to the repository development/library/javascript/react-primitive-components.

{ AggregateError: 
    SemanticReleaseError: The GitLab token doesn't allow to push on the repository development/library/javascript/react-primitive-components.
        at module.exports (/builds/development/library/javascript/react-primitive-components/node_modules/@semantic-release/gitlab/lib/get-error.js:6:10)
        at module.exports (/builds/development/library/javascript/react-primitive-components/node_modules/@semantic-release/gitlab/lib/verify.js:67:19)
    at /root/.npm/_npx/17/lib/node_modules/semantic-release/lib/plugins/pipeline.js:53:11
    at process._tickCallback (internal/process/next_tick.js:68:7) name: 'AggregateError' }ERROR: Job failed: exit code 1

.releaserc.yml:

release:
  branch: master

plugins:
  - "@semantic-release/commit-analyzer"
  - "@semantic-release/release-notes-generator"
  - - "@semantic-release/gitlab"
    - gitlabUrl: https://gitlabdev.paciolan.info
      verifyConditions: [] # this seems to have no effect
      assets:
        - path:
            - dist
            - README.md
          label: JS distribution

GITLAB_TOKEN permissions:

Name	Created	Expires	Scopes
semantic-release	Jan 28, 2019	In almost 80 years	api, read_user, read_repository	Revoke

I read through #19, but wasn't able to get any workarounds working for me.

At the moment, I am stuck and need some guidance to be pointed in the right direction on this.

Cheers!

Which package is correct?

Hi! I'm a bit confused…there are two packages in NPM purporting to be the Semantic Release Gitlab publisher—this one, called @semantic-release/gitlab and another called semantic-release-gitlab, can you give some clarification as to what the difference is?

An in-range update of got is breaking the build 🚨

The dependency got was updated from 9.3.1 to 9.3.2.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

got is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Status Details

• ❌ continuous-integration/travis-ci/push: The Travis CI build failed (Details).

---

Release Notes for v9.3.2

• No new timeouts after an error. d8dd881
• Fix the retry math. 07b3ce5

v9.3.1...v9.3.2

Commits

The new version differs by 3 commits.

• 4a383f2 9.3.2
• 07b3ce5 Fix the retry math (#653)
• d8dd881 No new timeouts after an error (#652)

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴

An in-range update of got is breaking the build 🚨

Version 9.1.0 of got was just published.

Branch	Build failing 🚨
Dependency	got
Current Version	9.0.0
Type	dependency

This version is covered by your current version range and after updating it in your project the build failed.

got is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Status Details

• ❌ continuous-integration/travis-ci/push: The Travis CI build failed (Details).

---

Release Notes

v9.1.0

• Add got.mergeInstances() which lets you easily compose multiple instances of Got into a single one. It's like plugins without any of the plugin mess. (#510) f0b190a
• Normalize the URL in the baseUrl option. (#579) c901c46
• Follow redirects with encoded URI. (#564) 3d98b9b
• Allow the query option to be a URLSearchParams instance. (#565) b8a086f
• Support retrying on 500 HTTP status code. a3e77de
• Bump get-stream to 0.4.0 for improved handling of stream edge-cases. (#578) 45d3a60
• Normalize the casing of the method option. (#547) ecf3180
• Fix the agent option with got.extend(). (#577) 2ffcd49
• Fix throwing errors when using got.stream(). (#550) ae5b114
• Ignore empty query objects. (#572) eb652f8

v9.0.0...v9.1.0

Commits

The new version differs by 24 commits.

• 1c54a03 9.1.0
• c901c46 Normalize the URL in the baseUrl option (#579)
• f241936 Remove AppVeyor
• 3d98b9b Follow redirects with encoded URI (#564)
• 45d3a60 Bump get-stream to 0.4.0 (#578)
• 2ffcd49 Don't freeze any other values than plain objects and arrays (#577)
• a7cd35a Tiny readme formatting tweak
• b8a086f Allow the query option to be a URLSearchParams instance (#565)
• 97533e5 Fix AWS example in readme (#575)
• 8f30f1f Add note about global-tunnel package
• eb652f8 Ignore empty query objects (#572)
• ca2675e Upgrade to [email protected]
• f30b623 Mention browser and Electron support in the comparison table (#556)
• a3e77de Support retrying on HTTP 500
• 2cdb3ed Fix a typo in the readme (#553)

There are 24 commits in total.

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴

Any way to use SSH key instead of GL_TOKEN/GITLAB_TOKEN?

We do not use personal access tokens across projects for write access. We do use SSH keys that we can set up per-project in GitLab.

Based on this comment: #64 (comment) - I was assuming that we could use an SSH key to drive this plugin but it doesn't seem like that's the case?

Is there any combination of variables I can set in GitLab or settings for this plugin to have this plugin drive via an SSH key (that's already added to ssh-agent during the run)?

Error: No token provided for GitLab

I am receiving the following error:

semantic-delivery-gitlab failed for the following reason - Error: No token provided for GitLab.

Both the environment variables GITLAB_TOKEN and GL_TOKEN are defined. I am running on Windows.

Tag is already created with semantic-release

Git tag is already created before the "publish" step with semantic-release

https://github.com/semantic-release/semantic-release/blob/b89523105cf04298f1f44858a02cc76c6c5dd0a5/index.js#L106

// Create the tag before calling the publish plugins as some require the tag to exists
    await tag(nextRelease.gitTag, {cwd, env});
    await push(options.repositoryUrl, options.branch, {cwd, env});
    logger.success(`Created tag ${nextRelease.gitTag}`);

    context.releases = await plugins.publish(context);

So the POST request fails when creating the tag.

Instead PUT request will update the created tag with associated notes

EGLNOPERMISSION and EINVALIDGLTOKEN thrown even with a valid token that has the correct permissions

Despite having set GITLAB_TOKEN with a valid token that has the correct permissions, I have the following error:

[8:33:25 AM] [semantic-release] [@semantic-release/gitlab] › ℹ  Verify GitLab authentication (https://gitlab.com/api/v4)
[8:33:26 AM] [semantic-release] › ✖  Failed step "verifyConditions" of plugin "@semantic-release/gitlab"
[8:33:26 AM] [semantic-release] › ✖  EGLNOPERMISSION The GitLab token doesn't allow to push on the repository root/my-project.
The user associated with the GitLab token (https://github.com/semantic-release/gitlab/blob/master/README.md#gitlab-authentication) configured in the GL_TOKEN or GITLAB_TOKEN environment variable must allows to push to the repository root/my-project.

Please make sure the GitLab user associated with the token has the permission to push (https://docs.gitlab.com/ee/user/permissions.html#project-members-permissions) to the repository root/my-project.

[8:33:26 AM] [semantic-release] › ✖  EINVALIDGLTOKEN Invalid GitLab token.
The GitLab token (https://github.com/semantic-release/gitlab/blob/master/README.md#gitlab-authentication) configured in the GL_TOKEN or GITLAB_TOKEN environment variable must be a valid personal access token (https://docs.gitlab.com/ce/user/profile/personal_access_tokens.html) allowing to push to the repository root/my-project.

Please make sure to set the GL_TOKEN or GITLAB_TOKEN environment variable in your CI with the exact value of the GitLab personal token.

AggregateError: 
    SemanticReleaseError: Invalid GitLab token.
        at module.exports (/usr/local/lib/node_modules/@semantic-release/gitlab/lib/get-error.js:6:10)
        at module.exports (/usr/local/lib/node_modules/@semantic-release/gitlab/lib/verify.js:58:21)
    SemanticReleaseError: The GitLab token doesn't allow to push on the repository root/my-project.
        at module.exports (/usr/local/lib/node_modules/@semantic-release/gitlab/lib/get-error.js:6:10)
        at module.exports (/usr/local/lib/node_modules/@semantic-release/gitlab/lib/verify.js:67:19)
    at /usr/local/lib/node_modules/semantic-release/lib/plugins/pipeline.js:54:11
    at processTicksAndRejections (internal/process/task_queues.js:93:5)
    at async Object.pluginsConf.<computed> [as verifyConditions] (/usr/local/lib/node_modules/semantic-release/lib/plugins/index.js:80:11)
    at async run (/usr/local/lib/node_modules/semantic-release/index.js:84:3)
    at async module.exports (/usr/local/lib/node_modules/semantic-release/index.js:170:22)
    at async module.exports (/usr/local/lib/node_modules/semantic-release/cli.js:55:5) {
  name: 'AggregateError'
}

My project has the id 3 on gitlab, I receive the correct response when doing the following curl:

$ curl --header "Private-Token: ${GITLAB_TOKEN}" ${GITLAB_URL}${GITLAB_PREFIX}/projects/3
{"id":3,"description":"","name":"my-project", ... }

However when doing a curl using the project's namespace (as does the plugin's code), I have the following response:

$ curl --header "Private-Token: ${GITLAB_TOKEN}" ${GITLAB_URL}${GITLAB_PREFIX}/projects/root%2Fmy-project
{"error":"404 Not Found"}

So here are several issues:

1. The plugin should not display both EGLNOPERMISSION and EINVALIDGLTOKEN. Either the token is valid and has not the right permissions, or it is invalid and being invalid it cannot have any permission anyway.
2. Some GitLab instances give a proper response when using the ID of the project, but a 404 error when using the project's namespace. The 404 is badly interpreted by the plugin.

Support different default branch names

If a repository's default branch is not master - it would be nice if semantic-release was able to just pick this up without needing configuration.

Gitlab provides this info as the environment variable CI_DEFAULT_BRANCH

Publish links instead of files

My project is building and releasing containers. How can i show links in the release notes? Currently it shows a list of files but is not ideal in my case as i rather have a link to an image in the container registry.

Does Not Support Subgroups

GitLab supports subgroups in organizations and parent subgroups. Currently this package assumes a (GitHub-like) owner/repo structure, breaking repos following a organization/group/repo structure.

"Validation failed: Description can't be blank"

Getting Response code 400 (Bad Request) when trying to publish release assets to GitLab.

This is the body of the request: body: '{"tag_name":"v5.5.0","description":""}' and this is the URL we are posting to: 'https://lab.arachnys.com/api/v4/projects/arachnys%2Farachnys-ui/repository/tags/v5.5.0/release' .
It looks like the description field of the body is blank, which is what is causing this problem, although I can't find any way to set a description message in your README.

Despite getting this error, the release tag is still updated on Gitlab, but with no assets.

This is the config in our .releaserc:

        ["@semantic-release/gitlab", {
            "assets": [
                {
                    "path": [
                        "package.json",
                        "dist/**/*.js",
                        "dist/**/*.d.ts",
                    ],
                    "label": "JS and TS declaration files"
                }
            ]
        }]

Let me know if you have any questions and I can provide more details. Thanks!

Support Links

Would like the ability to add links to the release. https://docs.gitlab.com/ee/user/project/releases/#links. Want to link to the produced docker image in the container registry.

An in-range update of sinon is breaking the build 🚨

Version 4.2.0 of sinon was just published.

Branch	Build failing 🚨
Dependency	sinon
Current Version	4.1.6
Type	devDependency

This version is covered by your current version range and after updating it in your project the build failed.

sinon is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details

• ❌ continuous-integration/travis-ci/push The Travis CI build could not complete due to an error Details

---

Commits

The new version differs by 9 commits.

• 5063c33 Update docs/changelog.md and set new release id in docs/_config.yml
• 28aee6f Add release documentation for v4.2.0
• 3cc6ac2 4.2.0
• 6444c67 Update History.md and AUTHORS for new release
• 3eaf042 Update package-lock.json
• f2d5902 Fix tests for IE11
• c5dfaae Add match.every and match.some (#1624) (#1661)
• 781429d Use "stale" as label for stale issues (#1658)
• acebab9 Documentation: async calls (#1286) (#1655)

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴

Gitlab user doesnt have access to push to the repo

Please help me solve this error message. I have created the Gitlab token, gave all the permissions to the token. I have access rights to push to the repo, which is a private project. I am still not able to use semantic-release. I guess I am doing something wrong but what exactly is the problem I am not able to find out. Below are the configs for my yml file and the semantic release logs.

package.json

"release": {
    "branch": "test",
    "plugins": [
      "@semantic-release/commit-analyzer",
      "@semantic-release/release-notes-generator",
      "@semantic-release/changelog",
      "@semantic-release/git",
      [
        "@semantic-release/gitlab",
        {
          "gitlabUrl": "https://gitlab*******.git"
        }
      ]
    ]
  }

gitlab.yml file

generate_changelog:
  stage: changelog
  script:
    - GL_TOKEN=$GL_TOKEN npx semantic-release --debug --no-ci
  only:
    - test

Semantic Release log

Running with gitlab-runner 11.11.2 (ac2a293c)
  on runner 7aae4c08
Using Docker executor with image node:11.15.0 ...
Pulling docker image node:11.15.0 ...
Using docker image sha256:58d70293b90018444a96aaa31ec0192b1e40f243effa266bdc231e55d879b777 for node:11.15.0 ...
Running on runner-7aae4c08-project-139-concurrent-0 via 7f334a473c6f...
Reinitialized existing Git repository in /builds/ma/ui_g2/.git/
Fetching changes...
Checking out 6192de7c as test...
Removing build/
Removing node_modules/

Skipping Git submodules setup
Checking cache for default...
No URL provided, cache will not be downloaded from shared cache server. Instead a local version of cache will be extracted. 
Successfully extracted cache
$ GL_TOKEN=$GL_TOKEN npx semantic-release --debug --no-ci
[6:06:32 AM] [semantic-release] › ℹ  Running semantic-release version 15.13.16
2019-06-11T06:06:32.748Z semantic-release:config load config from: /builds/ma/ui_g2/package.json
2019-06-11T06:06:32.753Z semantic-release:config options values: { branch: 'test',
  repositoryUrl: 'https://gitlab.orionic.com/ma/ui_g2',
  tagFormat: 'v${version}',
  plugins:
   [ '@semantic-release/commit-analyzer',
     '@semantic-release/release-notes-generator',
     '@semantic-release/changelog',
     '@semantic-release/git',
     [ '@semantic-release/gitlab', [Object] ] ],
  _: [],
  debug: true,
  ci: false,
  '$0': 'node_modules/.bin/semantic-release',
  noCi: true }
2019-06-11T06:06:33.004Z semantic-release:plugins options for @semantic-release/changelog/verifyConditions: {}
[6:06:33 AM] [semantic-release] › ✔  Loaded plugin "verifyConditions" from "@semantic-release/changelog"
2019-06-11T06:06:33.005Z semantic-release:plugins options for @semantic-release/git/verifyConditions: {}
[6:06:33 AM] [semantic-release] › ✔  Loaded plugin "verifyConditions" from "@semantic-release/git"
2019-06-11T06:06:33.005Z semantic-release:plugins options for @semantic-release/gitlab/verifyConditions: { gitlabUrl: 'https://gitlab.orionic.com/ma/ui_g2.git' }
[6:06:33 AM] [semantic-release] › ✔  Loaded plugin "verifyConditions" from "@semantic-release/gitlab"
2019-06-11T06:06:33.005Z semantic-release:plugins options for @semantic-release/commit-analyzer/analyzeCommits: {}
[6:06:33 AM] [semantic-release] › ✔  Loaded plugin "analyzeCommits" from "@semantic-release/commit-analyzer"
2019-06-11T06:06:33.006Z semantic-release:plugins options for @semantic-release/release-notes-generator/generateNotes: {}
[6:06:33 AM] [semantic-release] › ✔  Loaded plugin "generateNotes" from "@semantic-release/release-notes-generator"
2019-06-11T06:06:33.006Z semantic-release:plugins options for @semantic-release/changelog/prepare: {}
[6:06:33 AM] [semantic-release] › ✔  Loaded plugin "prepare" from "@semantic-release/changelog"
2019-06-11T06:06:33.006Z semantic-release:plugins options for @semantic-release/git/prepare: {}
[6:06:33 AM] [semantic-release] › ✔  Loaded plugin "prepare" from "@semantic-release/git"
2019-06-11T06:06:33.006Z semantic-release:plugins options for @semantic-release/gitlab/publish: { gitlabUrl: 'https://gitlab.orionic.com/ma/ui_g2.git' }
[6:06:33 AM] [semantic-release] › ✔  Loaded plugin "publish" from "@semantic-release/gitlab"
[6:06:33 AM] [semantic-release] › ✔  Run automated release from branch test
2019-06-11T06:06:33.215Z semantic-release:git Error: Command failed: git push --dry-run https://gitlab.orionic.com/ma/ui_g2 HEAD:test
remote: HTTP Basic: Access denied
fatal: Authentication failed for 'https://gitlab.orionic.com/ma/ui_g2.git/'


    at makeError (/builds/ma/ui_g2/node_modules/semantic-release/node_modules/execa/index.js:174:9)
    at Promise.all.then.arr (/builds/ma/ui_g2/node_modules/semantic-release/node_modules/execa/index.js:278:16)
    at processTicksAndRejections (internal/process/task_queues.js:86:5)
[6:06:33 AM] [semantic-release] › ✔  Allowed to push to the Git repository
[6:06:33 AM] [semantic-release] › ℹ  Start step "verifyConditions" of plugin "@semantic-release/changelog"
[6:06:33 AM] [semantic-release] › ✔  Completed step "verifyConditions" of plugin "@semantic-release/changelog"
[6:06:33 AM] [semantic-release] › ℹ  Start step "verifyConditions" of plugin "@semantic-release/git"
[6:06:33 AM] [semantic-release] › ✔  Completed step "verifyConditions" of plugin "@semantic-release/git"
[6:06:33 AM] [semantic-release] › ℹ  Start step "verifyConditions" of plugin "@semantic-release/gitlab"
2019-06-11T06:06:33.355Z semantic-release:gitlab repoId: 'ma/ui_g2'
2019-06-11T06:06:33.355Z semantic-release:gitlab apiUrl: 'https://gitlab.orionic.com/ma/ui_g2.git/api/v4'
[6:06:33 AM] [semantic-release] [@semantic-release/gitlab] › ℹ  Verify GitLab authentication (https://gitlab.orionic.com/ma/ui_g2.git/api/v4)
[6:06:33 AM] [semantic-release] › ✖  Failed step "verifyConditions" of plugin "@semantic-release/gitlab"
[6:06:33 AM] [semantic-release] › ✖  EGLNOPERMISSION The GitLab token doesn't allow to push on the repository ma/ui_g2.
The user associated with the GitLab token (https://github.com/semantic-release/gitlab/blob/master/README.md#gitlab-authentication) configured in the GL_TOKEN or GITLAB_TOKEN environment variable must allows to push to the repository ma/ui_g2.

Please make sure the GitLab user associated with the token has the permission to push (https://docs.gitlab.com/ee/user/permissions.html#project-members-permissions) to the repository ma/ui_g2.

[6:06:33 AM] [semantic-release] › ✖  EINVALIDGLTOKEN Invalid GitLab token.
The GitLab token (https://github.com/semantic-release/gitlab/blob/master/README.md#gitlab-authentication) configured in the GL_TOKEN or GITLAB_TOKEN environment variable must be a valid personnal access token (https://docs.gitlab.com/ce/user/profile/personal_access_tokens.html) allowing to push to the repository ma/ui_g2.

Please make sure to set the GL_TOKEN or GITLAB_TOKEN environment variable in your CI with the exact value of the GitLab personnal token.

{ AggregateError: 
    SemanticReleaseError: Invalid GitLab token.
        at module.exports (/builds/ma/ui_g2/node_modules/@semantic-release/gitlab/lib/get-error.js:6:10)
        at module.exports (/builds/ma/ui_g2/node_modules/@semantic-release/gitlab/lib/verify.js:58:21)
    SemanticReleaseError: The GitLab token doesn't allow to push on the repository ma/ui_g2.
        at module.exports (/builds/ma/ui_g2/node_modules/@semantic-release/gitlab/lib/get-error.js:6:10)
        at module.exports (/builds/ma/ui_g2/node_modules/@semantic-release/gitlab/lib/verify.js:67:19)
    at /builds/ma/ui_g2/node_modules/semantic-release/lib/plugins/pipeline.js:54:11
    at processTicksAndRejections (internal/process/task_queues.js:86:5) name: 'AggregateError' }ERROR: Job failed: exit code 1

Comment on issues resolved by current release

This may be on a roadmap but I didn't see any issues related to it so I figured I'd drop one here to at least indicate my support:

Similar to semantic-release/github, it would be awesome if the gitlab package had success/fail plugins to comment on issues related to the current release.

---

As an aside If I can get buy-in from my manager to work on this I'd be happy to but it's nothing to bank on

Plugin silently fails in CI job, but not in local env

With this log inside runner:

 [2:57:13 PM] [semantic-release] [@semantic-release/gitlab] › ℹ  Verify GitLab authentication (https://gitlab.com/api/v4)
 (node:42) Warning: Setting the NODE_TLS_REJECT_UNAUTHORIZED environment variable to '0' makes TLS connections and HTTPS requests insecure by disabling certificate verification.
Creating cache default...
 node_modules/: found 59442 matching files          
 Uploading cache.zip to ...
 Created cache
 Job succeeded

With this in local with --no-ci:

[18:03:40] [semantic-release] [@semantic-release/gitlab] › ℹ  Verify GitLab authentication (https://gitlab.com/api/v4)
(node:20915) Warning: Setting the NODE_TLS_REJECT_UNAUTHORIZED environment variable to '0' makes TLS connections and HTTPS requests insecure by disabling certificate verification.
[18:03:41] [semantic-release] › ✔  Completed step "verifyConditions" of plugin "@semantic-release/gitlab"
[18:03:41] [semantic-release] › ℹ  Found git tag v1.0.0 associated with version 1.0.0 on branch master
[18:03:41] [semantic-release] › ℹ  Found 15 commits since last release
[18:03:41] [semantic-release] › ℹ  Start step "analyzeCommits" of plugin "@semantic-release/commit-analyzer"
[18:03:41] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  Analyzing commit: Merge branch 'TASK-001' into 'master'
... rest of the release is successful

GitLab error 400 "released_at" is missing

I supposed GitLab updated their API because it used to work and without us changing anything we get now a 400 HTTP status code error. This happens when trying to publish the tag in GitLab.

Here are some details that we get from GitLab in our CI:
ERROR: null value in column "released_at" violates not-null constraint
INSERT INTO "releases" ("tag", "description", "project_id", "created_at", "updated_at", "description_html", "cached_markdown_version", "author_id", "name", "sha").

I cannot send the values in itself as they contain information on a private project I'm working on. If needed I could give the values types.

I browsed their API documentation and I didn't notice this field. Does anyone encounter a similar issue?

Versionning a NodeJS project using GitLab CI not working in verify conditions section

Environment

• semantic-release version: ^15.0.0
• CI environment: GitLab CI
• Plugins used:

semantic-release/commit-analyzer : ^8.0.0
release-notes-generator : ^9.0.0
gitlab : ^6.0.4
git : ^7.0.0

• semantic-release configuration:
  .releaserc.yml

plugins:
  - "@semantic-release/commit-analyzer"
  - "@semantic-release/release-notes-generator"
  - "@semantic-release/git"
  - "@semantic-release/gitlab"
      
branches:
  - "master"
  - "+([0-9])?(.{+([0-9]),x}).x"
  - name: "alpha"
    prerelease: "alpha"

.gitlab-ci.yml

    auto_increment:
      stage: auto_increment
      image: https://git.registry/dockerimages/node:13.16.3-stretch-git
      only:
        refs:
        - master
        - alpha
        # This matches maintenance branches
        - /^(([0-9]+)\.)?([0-9]+)\.x/
        # This matches pre-releases
        - /^([0-9]+)\.([0-9]+)\.([0-9]+)(?:-([0-9A-Za-z-]+(?:\.[0-9A-Za-z-]+)*))?(?:\+[0-9A-Za-z-]+)?$/
      script:
      - rm -f package-lock.json
      - npm install semantic-release --save-dev
      - npm install @semantic-release/gitlab 
      - npx semantic-release --debug

• CI logs:

[12:42:28 PM] [semantic-release] › ℹ  Running semantic-release version 15.14.0
 2020-07-06T12:42:28.229Z semantic-release:config load config from: /builds/bk/NodejsApp/.releaserc.yml
 2020-07-06T12:42:28.240Z semantic-release:config options values: {
   branch: 'master',
   repositoryUrl: 'https://[secure]@GitLabURI/bk/NodejsApp.git',
   tagFormat: 'v${version}',
   plugins: [
     '@semantic-release/commit-analyzer',
     '@semantic-release/release-notes-generator',
     '@semantic-release/git',
     '@semantic-release/npm',
     '@semantic-release/gitlab'
   ],
   branches: [
     'master',
     '+([0-9])?(.{+([0-9]),x}).x',
     { name: 'alpha', prerelease: 'alpha' }
   ],
   _: [],
   debug: true,
   '$0': 'node_modules/.bin/semantic-release'
 }
 2020-07-06T12:42:28.433Z semantic-release:plugins options for @semantic-release/git/verifyConditions: {}
 [12:42:28 PM] [semantic-release] › ✔  Loaded plugin "verifyConditions" from "@semantic-release/git"
 2020-07-06T12:42:28.435Z semantic-release:plugins options for @semantic-release/npm/verifyConditions: {}
 2020-07-06T12:42:28.436Z semantic-release:plugins options for @semantic-release/gitlab/verifyConditions: {}
 2020-07-06T12:42:28.436Z semantic-release:plugins options for @semantic-release/commit-analyzer/analyzeCommits: {}
 2020-07-06T12:42:28.436Z semantic-release:plugins options for @semantic-release/release-notes-generator/generateNotes: {}
 2020-07-06T12:42:28.437Z semantic-release:plugins options for @semantic-release/git/prepare: {}
 2020-07-06T12:42:28.437Z semantic-release:plugins options for @semantic-release/npm/prepare: {}
 [12:42:28 PM] [semantic-release] › ✔  Loaded plugin "verifyConditions" from "@semantic-release/npm"
 [12:42:28 PM] [semantic-release] › ✔  Loaded plugin "verifyConditions" from "@semantic-release/gitlab"
 [12:42:28 PM] [semantic-release] › ✔  Loaded plugin "analyzeCommits" from "@semantic-release/commit-analyzer"
 [12:42:28 PM] [semantic-release] › ✔  Loaded plugin "generateNotes" from "@semantic-release/release-notes-generator"
 [12:42:28 PM] [semantic-release] › ✔  Loaded plugin "prepare" from "@semantic-release/git"
 [12:42:28 PM] [semantic-release] › ✔  Loaded plugin "prepare" from "@semantic-release/npm"
 [12:42:28 PM] [semantic-release] › ✔  Loaded plugin "publish" from "@semantic-release/npm"
 [12:42:28 PM] [semantic-release] › ✔  Loaded plugin "publish" from "@semantic-release/gitlab"
 2020-07-06T12:42:28.437Z semantic-release:plugins options for @semantic-release/npm/publish: {}
 2020-07-06T12:42:28.438Z semantic-release:plugins options for @semantic-release/gitlab/publish: {}
 [12:42:28 PM] [semantic-release] › ✔  Run automated release from branch master
 [12:42:29 PM] [semantic-release] › ✔  Allowed to push to the Git repository
 [12:42:29 PM] [semantic-release] › ℹ  Start step "verifyConditions" of plugin "@semantic-release/git"
 [12:42:29 PM] [semantic-release] › ✔  Completed step "verifyConditions" of plugin "@semantic-release/git"
 [12:42:29 PM] [semantic-release] › ℹ  Start step "verifyConditions" of plugin "@semantic-release/npm"
 [12:42:29 PM] [semantic-release] › ✔  Completed step "verifyConditions" of plugin "@semantic-release/npm"
 [12:42:29 PM] [semantic-release] › ℹ  Start step "verifyConditions" of plugin "@semantic-release/gitlab"
 [12:42:29 PM] [semantic-release] [@semantic-release/gitlab] › ℹ  Verify GitLab authentication (https://GitLabURI/api/v4)
 2020-07-06T12:42:29.039Z semantic-release:gitlab apiUrl: 'https://GitLabURI/api/v4'
 2020-07-06T12:42:29.039Z semantic-release:gitlab repoId: 'bk/NodejsApp'
 [12:42:29 PM] [semantic-release] › ✖  Failed step "verifyConditions" of plugin "@semantic-release/gitlab"
 [12:42:29 PM] [semantic-release] › ✖  An error occurred while running semantic-release: TypeError: Cannot read property 'statusCode' of undefined
     at module.exports (/builds/bk/NodejsApp/node_modules/@semantic-release/gitlab/lib/verify.js:62:26)
     at processTicksAndRejections (internal/process/task_queues.js:97:5) {
   pluginName: '@semantic-release/gitlab'
 }
 AggregateError: 
     TypeError: Cannot read property 'statusCode' of undefined
         at module.exports (/builds/bk/NodejsApp/node_modules/@semantic-release/gitlab/lib/verify.js:62:26)
     at /builds/bk/NodejsApp/node_modules/semantic-release/lib/plugins/pipeline.js:54:11
     at processTicksAndRejections (internal/process/task_queues.js:97:5)
     at async Object.pluginsConf.<computed> [as verifyConditions] (/builds/bk/NodejsApp/node_modules/semantic-release/lib/plugins/index.js:80:11)
     at async run (/builds/bk/NodejsApp/node_modules/semantic-release/index.js:84:3)
     at async module.exports (/builds/bk/NodejsApp/node_modules/semantic-release/index.js:176:22)
     at async module.exports (/builds/bk/NodejsApp/node_modules/semantic-release/cli.js:55:5)
 ERROR: Job failed: command terminated with exit code 1

An in-range update of nock is breaking the build 🚨

☝️ Greenkeeper’s updated Terms of Service will come into effect on April 6th, 2018.

Version 9.2.1 of nock was just published.

Branch	Build failing 🚨
Dependency	nock
Current Version	9.2.0
Type	devDependency

This version is covered by your current version range and after updating it in your project the build failed.

nock is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details

• ❌ continuous-integration/travis-ci/push The Travis CI build could not complete due to an error Details

---

Release Notes

v9.2.1

9.2.1 (2018-02-24)

Bug Fixes

• package: update chai, lodash, propagate, qs (aed9166)

Commits

The new version differs by 11 commits.

• b373339 build(package): -restify, +restify-clients
• 6c9760f test: restify -> restify-clients
• 841cf54 build(package): -restler
• 645d269 refactor: remove use of restler in tests
• a3b6560 build(package): update dev dependencies
• aed9166 fix(package): update chai, lodash, propagate, qs
• f8dd092 ci(travis): stages
• 2ced38e test: remove obsolete versioned folder
• 969af67 ci(travis): remove integration test
• 057f8fb test: remove versioned tests with request, got and posicle
• 6bff991 test(package): remove integration tests (versioned tests with request libraries)

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴

Failed step "verifyConditions" with EINVALIDGLTOKEN and EGITNOPERMISSION error

I have been trying to figure this out for quite sometime now and i have tried all possible ways that i can think of.

The build is always failing with the following logs

[8:38:37 AM] [semantic-release] › ℹ  Running semantic-release version 15.13.3
[8:38:37 AM] [semantic-release] › ✔  Loaded plugin "verifyConditions" from "@semantic-release/gitlab"
[8:38:37 AM] [semantic-release] › ✔  Loaded plugin "analyzeCommits" from "@semantic-release/commit-analyzer"
[8:38:37 AM] [semantic-release] › ✔  Loaded plugin "generateNotes" from "@semantic-release/release-notes-generator"
[8:38:37 AM] [semantic-release] › ✔  Loaded plugin "publish" from "@semantic-release/gitlab"
[8:38:37 AM] [semantic-release] › ✔  Run automated release from branch master
[8:38:38 AM] [semantic-release] › ✔  Allowed to push to the Git repository
[8:38:38 AM] [semantic-release] › ℹ  Start step "verifyConditions" of plugin "@semantic-release/gitlab"
[8:38:38 AM] [semantic-release] [@semantic-release/gitlab] › ℹ  Verify GitLab authentication (https://gitlab.com/mygroup/myrepo.git/api/v4)
[8:38:38 AM] [semantic-release] › ✖  Failed step "verifyConditions" of plugin "@semantic-release/gitlab"
[8:38:38 AM] [semantic-release] › ✖  EINVALIDGLTOKEN Invalid GitLab token.
....
[8:38:38 AM] [semantic-release] › ✖  EGLNOPERMISSION The GitLab token doesn't allow to push on the repository mygroup/myrepo.
....

weather i set the variables in gitlab CI/CD settings or in the .releaserc or in the gitlab.ci.yml all of these didn't work i even tried to put "verifyConditions": [], in the @semantic-release/gitlab options in the .releserc file

I have referred to this issue #19 but couldn't get much and in my case it's simply a project under a group not under a subgroup

any ideas on how i can get this work?

GITLAB_URL & GITLAB_PREFIX can be replaced by CI_API_V4_URL and be optional for any gitlab instance since 11.7

GITLAB_URL & GITLAB_PREFIX can be replaced by CI_API_V4_URL and be optional for any gitlab instance since 11.7

https://docs.gitlab.com/ee/ci/variables/predefined_variables.html

verifyConditions step fails in subgroup projects

My organization has a private GitLab instance where it's quite common to organize projects into group/subgroup relationships. I did find issue #2, but that seems to be strictly related to the usage of / in project names and properly encoding that for the API url.

I've hunted down the cause of this issue, and I believe it lies in the odd behavior of permission inheritance in GitLab. When making the API call to fetch the project with the access token provided, if the associated user has push privileges on a containing group level, but isn't added as an explicit member to the project, the API responds with the following permissions:

...
    "permissions": {
        "project_access": null,
        "group_access": null
    }
...

Repro:

1. Create a group in GitLab (e.g. gitlab.com/foo)
2. Create a subgroup under the previous group (e.g. gitlab.com/foo/bar)
3. Create a project under the subgroup (e.g. gitlab.com/foo/bar/baz)
4. Add a user with permissions to push (e.g. Master) to the "foo" group
5. Generate an access token for that user with read_user, api permissions
6. Add that token to baz (can also be added at the group levels for either foo or bar) as GL_TOKEN
7. Commit to baz with a .gitlab-ci.yml file configured to call semantic-release with @semantic-release/gitlab

Expected Behavior

The build and release succeeds

Actual Behavior:

The build fails with EGHNOPERMISSION at the verifyConditions step of @semantic-release/gitlab

Workaround

A bit annoying, but you can assign the user explicitly to each project you want to use semantic-release/gitlab with.

An in-range update of nock is breaking the build 🚨

Version 9.3.1 of nock was just published.

Branch	Build failing 🚨
Dependency	nock
Current Version	9.3.0
Type	devDependency

This version is covered by your current version range and after updating it in your project the build failed.

nock is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details

• ❌ continuous-integration/travis-ci/push The Travis CI build could not complete due to an error Details

---

Release Notes

v9.3.1

9.3.1 (2018-06-07)

Bug Fixes

• use aborted property on http request (#1134) (aaa9a56)

Commits

The new version differs by 3 commits.

• aaa9a56 fix: use aborted property on http request (#1134)
• e933b3a refactor: update Buffer constructors to from and alloc (#1141)
• d3f5b3f chore(package): update nyc to version 12.0.1

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴

verification failed when user added via group sharing

currently verification relies on api/v4/projects/${PROJECT_ID} and fails when project is shared with group and user is member of that group, because in such situation API says project_level and group_level are null. Thus we end up in the situation when user has all required permissions, but verification fails.

It's already reported to GitLab https://gitlab.com/gitlab-org/gitlab/-/issues/223832, but still I believe it's a bug that should be fixed here - verification says "no permissions", while user has all required permissions.

Cannot configure GITLAB_URL

Setting the GITLAB_URL environment variable doesn't seem to affect the URL where semantic-release is publishing to.

Package.json

{
    ...
    "release": {
    "branch": "feature/semantic-release",
    "plugins": [
      "@semantic-release/commit-analyzer",
      "@semantic-release/release-notes-generator",
      "@semantic-release/gitlab"
    ]
  }
}

Logs

Notice the Username for 'https://gitlab.com'

> echo $GITLAB_URL
https://ilias.gitlab.com
> yarn semantic-release
yarn run v1.17.3
$ .../node_modules/.bin/semantic-release
[4:48:53 PM] [semantic-release] › ℹ  Running semantic-release version 15.13.28
[4:48:53 PM] [semantic-release] › ✔  Loaded plugin "verifyConditions" from "@semantic-release/gitlab"
[4:48:53 PM] [semantic-release] › ✔  Loaded plugin "analyzeCommits" from "@semantic-release/commit-analyzer"
[4:48:53 PM] [semantic-release] › ✔  Loaded plugin "generateNotes" from "@semantic-release/release-notes-generator"
[4:48:53 PM] [semantic-release] › ✔  Loaded plugin "publish" from "@semantic-release/gitlab"
[4:48:53 PM] [semantic-release] › ⚠  This run was not triggered in a known CI environment, running in dry-run mode.
[4:48:53 PM] [semantic-release] › ⚠  Run automated release from branch feature/semantic-release in dry-run mode
Username for 'https://gitlab.com': 

Environment

• MacOS 10.14.5
• Node 11.10.1
• NPM v6.7.0

How do I configure the gitlab URL to point to my private gitlab?

Wrong configuration in README.md

Expected

The README.md should document how to configure properly

Problem

The README.md information are conflicting with the semantic CLi output

Reproduction

In readme.md:

{
  "release": {
    "verifyConditions": [
      "@semantic-release/npm",
      "@semantic-release/git",
      {
        "path": "@semantic-release/gitlab",
        "gitlabUrl": "https://custom.gitlab.com"
      }
    ],
    "publish": [
      "@semantic-release/npm",
      "@semantic-release/git", // <==== This is not allowed by the cli
      {
        "path": "@semantic-release/gitlab",
        "gitlabUrl": "https://custom.gitlab.com"
      }
    ]
  }
}

In cli:

Semantic release]: EPLUGIN A plugin configured in the step publish is not a valid semantic-release plugin.
A valid publish semantic-release plugin must be a function or an object with a function in the property publish.

The plugin @semantic-release/git doesn't have the property publish and cannot be used for the publish step.

Please refer to the @semantic-release/git and semantic-release plugins configuration (https://github.com/semantic-release/semantic-release/blob/caribou/docs/usage/plugins.md) documentation for more details.

Also, I would like to attract your interest on semantic-release/git#49

I was not able to configure assets for GitLab using the git plugin, is it working with GitLab ?

By reading the documentation in semantic-release/git, it is seems to be possible but it is not working.

Verification stopped with node v13

The exact same Gitlab CI config (apart from the node version) has different results:

In node 13 the process stops after auth verification:

$ semantic-release
[11:31:45 AM] [semantic-release] › ℹ  Running semantic-release version 17.0.4
[11:31:45 AM] [semantic-release] › ✔  Loaded plugin "verifyConditions" from "@semantic-release/gitlab"
[11:31:45 AM] [semantic-release] › ✔  Loaded plugin "verifyConditions" from "@semantic-release/npm"
[11:31:45 AM] [semantic-release] › ✔  Loaded plugin "analyzeCommits" from "@semantic-release/commit-analyzer"
[11:31:45 AM] [semantic-release] › ✔  Loaded plugin "generateNotes" from "@semantic-release/release-notes-generator"
[11:31:45 AM] [semantic-release] › ✔  Loaded plugin "prepare" from "@semantic-release/npm"
[11:31:45 AM] [semantic-release] › ✔  Loaded plugin "publish" from "@semantic-release/gitlab"
[11:31:45 AM] [semantic-release] › ✔  Loaded plugin "publish" from "@semantic-release/npm"
[11:31:45 AM] [semantic-release] › ✔  Loaded plugin "addChannel" from "@semantic-release/npm"
[11:31:46 AM] [semantic-release] › ✔  Run automated release from branch master on repository https://gitlab-ci-token:[secure]@git.startinblox.com/applications/faabrick-cherdet/faabrick_app.git
[11:31:46 AM] [semantic-release] › ✔  Allowed to push to the Git repository
[11:31:46 AM] [semantic-release] › ℹ  Start step "verifyConditions" of plugin "@semantic-release/gitlab"
[11:31:46 AM] [semantic-release] [@semantic-release/gitlab] › ℹ  Verify GitLab authentication (https://git.startinblox.com/api/v4)
Job succeeded

I tried --debug but it didn't give me anything helpfull.

In node 11:

$ semantic-release
[2:13:16 PM] [semantic-release] › ℹ  Running semantic-release version 17.0.4
[2:13:16 PM] [semantic-release] › ✔  Loaded plugin "verifyConditions" from "@semantic-release/gitlab"
[2:13:16 PM] [semantic-release] › ✔  Loaded plugin "verifyConditions" from "@semantic-release/npm"
[2:13:16 PM] [semantic-release] › ✔  Loaded plugin "analyzeCommits" from "@semantic-release/commit-analyzer"
[2:13:16 PM] [semantic-release] › ✔  Loaded plugin "generateNotes" from "@semantic-release/release-notes-generator"
[2:13:16 PM] [semantic-release] › ✔  Loaded plugin "prepare" from "@semantic-release/npm"
[2:13:16 PM] [semantic-release] › ✔  Loaded plugin "publish" from "@semantic-release/gitlab"
[2:13:16 PM] [semantic-release] › ✔  Loaded plugin "publish" from "@semantic-release/npm"
[2:13:16 PM] [semantic-release] › ✔  Loaded plugin "addChannel" from "@semantic-release/npm"
[2:13:17 PM] [semantic-release] › ✔  Run automated release from branch master on repository https://gitlab-ci-token:[secure]@git.startinblox.com/applications/faabrick-cherdet/faabrick_app.git
[2:13:17 PM] [semantic-release] › ✔  Allowed to push to the Git repository
[2:13:17 PM] [semantic-release] › ℹ  Start step "verifyConditions" of plugin "@semantic-release/gitlab"
[2:13:17 PM] [semantic-release] [@semantic-release/gitlab] › ℹ  Verify GitLab authentication (https://git.startinblox.com/api/v4)
[2:13:17 PM] [semantic-release] › ✔  Completed step "verifyConditions" of plugin "@semantic-release/gitlab"
[2:13:17 PM] [semantic-release] › ℹ  Start step "verifyConditions" of plugin "@semantic-release/npm"
[2:13:17 PM] [semantic-release] [@semantic-release/npm] › ℹ  Verify authentication for registry https://registry.npmjs.org/
[2:13:17 PM] [semantic-release] [@semantic-release/npm] › ℹ  Wrote NPM_TOKEN to /tmp/9ccebbc97b356d69ba6af5627bfc78c9/.npmrc
startinbloxbot
[2:13:18 PM] [semantic-release] › ✔  Completed step "verifyConditions" of plugin "@semantic-release/npm"
[2:13:18 PM] [semantic-release] › ℹ  Found git tag v0.2.6 associated with version 0.2.6 on branch master
[2:13:18 PM] [semantic-release] › ℹ  Found 8 commits since last release
[2:13:18 PM] [semantic-release] › ℹ  Start step "analyzeCommits" of plugin "@semantic-release/commit-analyzer"
[2:13:18 PM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  Analyzing commit: cicd: debuging CI
[2:13:18 PM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  The release type for the commit is patch
[2:13:18 PM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  Analyzing commit: cicd: debuging CI
[2:13:18 PM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  The release type for the commit is patch
[2:13:18 PM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  Analyzing commit: cicd: debuging CI
[2:13:18 PM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  The release type for the commit is patch
[2:13:18 PM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  Analyzing commit: cicd: adding dry run mode
[2:13:18 PM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  The release type for the commit is patch
[2:13:18 PM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  Analyzing commit: cicd: adding debug mode
[2:13:18 PM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  The release type for the commit is patch
[2:13:18 PM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  Analyzing commit: cicd: forced checking out commit for analyze
[2:13:18 PM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  The release type for the commit is patch
[2:13:18 PM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  Analyzing commit: cicd: forced version bump
[2:13:18 PM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  The release type for the commit is patch
[2:13:18 PM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  Analyzing commit: update: siren + position of popup
[2:13:18 PM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  The release type for the commit is patch
[2:13:18 PM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  Analysis of 8 commits complete: patch release
[2:13:18 PM] [semantic-release] › ✔  Completed step "analyzeCommits" of plugin "@semantic-release/commit-analyzer"
[2:13:18 PM] [semantic-release] › ℹ  The next release version is 0.2.7
[2:13:18 PM] [semantic-release] › ℹ  Start step "generateNotes" of plugin "@semantic-release/release-notes-generator"
[2:13:18 PM] [semantic-release] › ✔  Completed step "generateNotes" of plugin "@semantic-release/release-notes-generator"
[2:13:18 PM] [semantic-release] › ℹ  Start step "prepare" of plugin "@semantic-release/npm"
[2:13:18 PM] [semantic-release] [@semantic-release/npm] › ℹ  Write version 0.2.7 to package.json in /builds/applications/faabrick-cherdet/Faabrick_app
v0.2.7
[2:13:18 PM] [semantic-release] › ✔  Completed step "prepare" of plugin "@semantic-release/npm"
[2:13:19 PM] [semantic-release] › ✔  Created tag v0.2.7
[2:13:19 PM] [semantic-release] › ℹ  Start step "publish" of plugin "@semantic-release/gitlab"
[2:13:19 PM] [semantic-release] [@semantic-release/gitlab] › ℹ  Published GitLab release: v0.2.7
[2:13:19 PM] [semantic-release] › ✔  Completed step "publish" of plugin "@semantic-release/gitlab"
[2:13:19 PM] [semantic-release] › ℹ  Start step "publish" of plugin "@semantic-release/npm"
[2:13:19 PM] [semantic-release] [@semantic-release/npm] › ℹ  Publishing version 0.2.7 to npm registry on dist-tag latest
npm notice 
npm notice package: @startinblox/[email protected]
npm notice === Tarball Contents === 
npm notice 1.2kB package.json       
npm notice 226B  .gitlab-ci.yml     
npm notice 526B  index.html         
npm notice 20B   README.md          
npm notice 692B  server.js          
npm notice 3.7kB sib-faabrickmap.js 
npm notice 4.9kB css/faabrickmap.css
npm notice === Tarball Details === 
npm notice name:          @startinblox/faabrickmap                
npm notice version:       0.2.7                                   
npm notice package size:  3.9 kB                                  
npm notice unpacked size: 11.2 kB                                 
npm notice shasum:        bb407e38393a0c58ee6918cb1e77a85993b3a6d9
npm notice integrity:     sha512-hIJDyJiqIlZYF[...]ogfRDlgbp4lQg==
npm notice total files:   7                                       
npm notice 
+ @startinblox/[email protected]
[2:13:24 PM] [semantic-release] [@semantic-release/npm] › ℹ  Published @startinblox/[email protected] to dist-tag @latest on https://registry.npmjs.org/
[2:13:24 PM] [semantic-release] › ✔  Completed step "publish" of plugin "@semantic-release/npm"
[2:13:24 PM] [semantic-release] › ✔  Published release 0.2.7 on default channel
Job succeeded

break down doc examples to indicate they are options

By following the docs, one can assume that these two properties are required:
Option one:

"@semantic-release/gitlab",

Option two:

{
  "path": "@semantic-release/gitlab",
  "gitlabUrl": "https://custom.gitlab.com"
}

But by doing so I was getting a 409 Conflict http error.

I want to suggest explaining that they are alternatives, willing to make a PR if you think this will be useful.

Versioning not properly functioning with merge requests

Hi all

Thanks for this plugin!

I have set it up on one of our repositories and with the following setup:

• production branch (default)
• beta (prerelease)
• alpha (prerelease)

semantic-release config in package.json:

"release": {
    "branches": [
      "+([0-9])?(.{+([0-9]),x}).x",
      "production",
      {
        "name": "beta",
        "prerelease": true
      },
      {
        "name": "alpha",
        "prerelease": true
      }
    ],
    "plugins": [
      "@semantic-release/commit-analyzer",
      "@semantic-release/release-notes-generator",
      [
        "@semantic-release/gitlab",
        {
          "gitlabUrl": "https://gitlab.com"
        }
      ],
      [
        "@semantic-release/npm",
        {
          "npmPublish": false
        }
      ]
    ],
    "verifyConditions": [
      "@semantic-release/gitlab"
    ],
}

I may not correctly understand it, but the desired workflow is:

• developers create a feat/xyz branch from alpha
• afterwards, they merge the feature branch into alpha
• merge alpha into beta
• beta into production

As you can see on the following screenshot the tags are not correctly generated. Do I forget something during the merge/commit process?

• The last production release was 1.3.0.
• When creating the new feature branch and merging it into alpha, the new alpha tag with 1.4.0-alpha.1 is created.
• When merging alpha into beta, it somehow creates a tag/release for 1.0.0-beta.5. I would expect this to be 1.4.0-beta.1

Any clues and ideas are much appreciated!

Thank you

Automatically populate gitlabUrl when running from gitlab pipelines

When using gitlab pipelines, it would be nice to populate gitlabUrl and gitlabApiPathPrefix automatically, as the necessary values are provided by the pipelines:

Gitlab pipelines provide the following environment variables out of the box:

• CI_API_V4_URL is directly the api url, replacing GITLAB_URL and GITLAB_PREFIX
• CI_SERVER_HOST is the GitLab hostname, replacing GITLAB_URL

$ echo ${GITLAB_URL}
https://gitlab.local/

$ echo ${CI_API_V4_URL}
https://gitlab.local/api/v4

$ echo ${CI_SERVER_HOST}
gitlab.local

It is a shame to be oblige to declare the GitLab url into a GitLab CI pipeline. GitLab knows about its own url.

Originally posted by @oupala in #105 (comment)

Beta for [email protected] (multi-channels)

Hello. Do you have any plans to update this package for compatibility with [email protected] (multi-channel releases)? All packages has been already updated and this is the last one :)

gitlabUrl could be retrieved from package.json

The gitlabUrl value is currently is retrieved from an environment variable (or has a default value) (see documentation):

GL_URL or GITLAB_URL environment variable or https://gitlab.com

In fact the information is already available in the package.json file (if any) in the repository.url field. Could it be a source of information sourced, in order to avoid repeating the same information?

This usecase is already implemented in the npm plugin where the private field is checked to see if the npm package should be published to npmjs or not.