code 400

[ldc2726]

021-05-20T05:02:43.750Z semantic-release:git commited files: [ 'CHANGELOG.md' ]
[1:02:44 PM] [semantic-release] [@semantic-release/git] › ℹ Prepared Git release: v1.2.5
[1:02:44 PM] [semantic-release] › ✔ Completed step "prepare" of plugin "@semantic-release/git"
[1:02:44 PM] [semantic-release] › ℹ Start step "generateNotes" of plugin "@semantic-release/release-notes-generator"
2021-05-20T05:02:44.648Z semantic-release:release-notes-generator version: '1.2.5'
2021-05-20T05:02:44.648Z semantic-release:release-notes-generator host: undefined
2021-05-20T05:02:44.648Z semantic-release:release-notes-generator owner: 'dyWeb'
2021-05-20T05:02:44.648Z semantic-release:release-notes-generator repository: 'DataCockpit/demo'
2021-05-20T05:02:44.648Z semantic-release:release-notes-generator previousTag: 'v1.2.4'
2021-05-20T05:02:44.648Z semantic-release:release-notes-generator currentTag: 'v1.2.5'
2021-05-20T05:02:44.648Z semantic-release:release-notes-generator host: 'http://192.168.1.184'
2021-05-20T05:02:44.648Z semantic-release:release-notes-generator linkReferences: undefined
2021-05-20T05:02:44.648Z semantic-release:release-notes-generator issue: 'issues'
2021-05-20T05:02:44.648Z semantic-release:release-notes-generator commit: 'commit'
[1:02:44 PM] [semantic-release] › ✔ Completed step "generateNotes" of plugin "@semantic-release/release-notes-generator"
[1:02:46 PM] [semantic-release] › ✔ Created tag v1.2.5
[1:02:46 PM] [semantic-release] › ℹ Start step "publish" of plugin "@semantic-release/gitlab"
2021-05-20T05:02:46.971Z semantic-release:gitlab repoId: 'dyWeb/DataCockpit/demo'
2021-05-20T05:02:46.971Z semantic-release:gitlab release name: 'v1.2.5'
2021-05-20T05:02:46.971Z semantic-release:gitlab release ref: '852ee054f6c68bab2084651f7598d2f74ad2face'
2021-05-20T05:02:46.971Z semantic-release:gitlab Create a release for git tag 'v1.2.5' with commit '852ee054f6c68bab2084651f7598d2f74ad2face'
gitlabApiUrl: http://192.168.1.184/api/v4 /projects/dyWeb%2FDataCockpit%2Fdemo/release
apiOptions: { headers: { 'PRIVATE-TOKEN': '[secure]' } }
v1.2.5 ## 1.2.5 (2021-05-20)

Bug Fixes

• 分开一个分之测试 (30ce41a)

[]
[1:02:47 PM] [semantic-release] › ✖ Failed step "publish" of plugin "@semantic-release/gitlab"
[1:02:47 PM] [semantic-release] › ✖ An error occurred while running semantic-release: HTTPError: Response code 400 (Bad Request)
at EventEmitter. (/usr/local/lib/node_modules/@semantic-release/gitlab/node_modules/got/dist/source/as-promise.js:118:31)
at processTicksAndRejections (internal/process/task_queues.js:97:5) {
pluginName: '@semantic-release/gitlab'
}
HTTPError: Response code 400 (Bad Request)
at EventEmitter. (/usr/local/lib/node_modules/@semantic-release/gitlab/node_modules/got/dist/source/as-promise.js:118:31)
at processTicksAndRejections (internal/process/task_queues.js:97:5) {
pluginName: '@semantic-release/gitlab'
}ERROR: Job failed: exit status 1

[ldc2726]

help,,,,,,why????

[ldc2726]

{
"branches": [
"+([0-9])?(.{+([0-9]),x}).x",
"master",
"next",
{"name": "beta", "prerelease": true},
{"name": "alpha", "prerelease": true}
],
"plugins": [
"@semantic-release/commit-analyzer",
"@semantic-release/release-notes-generator",
"@semantic-release/changelog",
[
"@semantic-release/gitlab",
{
"assets": [
{ "path": "dist/*.html", "label": "html distribution" }
]
}
],
[
"@semantic-release/git",
{
"assets": [
"package.json",
"CHANGELOG.md"
],
"message": "chore(release): ${nextRelease.version} [skip ci]\n\n${nextRelease.notes}"
}
],
]
}

[ldc2726]

before:

add "name":

after：

I tried to add the attribute "name" to the body, and the result was successful. I hope to optimize it as soon as possible, I think it may be a bug, thank you

[nfriend]

@ldc2726 Thanks for reporting! Very weird. According to the docs, the name attribute is optional - if it's omitted, it defaults to the tag_name property.

I just confirmed this myself by POSTing to a test project on GitLab.com with the following body:

{
    "tag_name": "v5.5"
}

and the release was successfully created: https://gitlab.com/nfriend/release-test/-/releases/v5.5

But your screenshots make it very clear that the missing name property is causing this error 🤔

What version of GitLab are using? Also, what permissions do you have on the project? (Developer, Maintainer, Owner, etc.)

[ldc2726]

@nfriend
1.Owner
2.

No matter what version is causing the problem, I still want to be as compatible as possible by adding the "name" attribute to it，thank you!

[nfriend]

@ldc2726 Ah, yep, the GitLab version is the culprit!

I looks like this attribute was required in GitLab 11.X, but then changed to be optional in GitLab 12.X.

I'm a little unsure what to do here, since according to Gitlab's support schedule, 11.X will become unsupported in 28 days (when GitLab 14.0 is released).

The best solution is to upgrade from 11.X. But I also understand this is a big undertaking and maybe not within your control.

If upgrading is really not a solution for you, you could:

1. Submit a PR that adds the name attribute to the request
2. Include a comment above the line that indicates this is only for compatibility with an unsupported version of GitLab
3. Update the docs with an explicit list of all supported GitLab versions

WDYT?

[ldc2726]

Well, I chose to submit a PR so that more people could avoid this problem.
#240

[nfriend]

Thanks @ldc2726! I won't have time to review this week but will prioritize this next week!

[alecgerona]

Also seems to happen on Gitlab.com.

Same 400 error code but not really sure if the same cause of failure since the reason is not explicitly logged.

[joffreyvillard]

Hi!

I have been also experiencing this issue for a few days now (using Gitlab SaaS).

The "publish" steps fails with a 400 code (now 404) - below are some logs I get in my CI job (running in Docker).
The tag is well created in Gitlab, but no release notes are pushed.

I suspect it to be linked with the very recent deployment of the new 14.0 version of Gitlab ("will go live on GitLab.com sometime between May 23 – June 22"), which full change log (available here: https://about.gitlab.com/blog/2021/06/04/gitlab-moving-to-14-breaking-changes/) includes the below elements:

[3:58:31 PM] [semantic-release] › ✖  An error occurred while running semantic-release: HTTPError: Response code 404 (Not Found)
    at EventEmitter.<anonymous> (/usr/local/lib/node_modules/@semantic-release/gitlab/node_modules/got/dist/source/as-promise.js:118:31)
    at processTicksAndRejections (internal/process/task_queues.js:93:5) {
  pluginName: '@semantic-release/gitlab'
}
HTTPError: Response code 404 (Not Found)
    at EventEmitter.<anonymous> (/usr/local/lib/node_modules/@semantic-release/gitlab/node_modules/got/dist/source/as-promise.js:118:31)
    at processTicksAndRejections (internal/process/task_queues.js:93:5) {
  pluginName: '@semantic-release/gitlab'
}

[nfriend]

@joffreyvillard That's very possible! Are you using the latest version of @semantic-release/gitlab? This plugin was updated to stop using the deprecated API in #184, which is included in version 6.0.7 and beyond.

[nfriend]

Same 400 error code but not really sure if the same cause of failure since the reason is not explicitly logged.

@alecgerona I agree explicitly logging the error code is a good step 👍 I'll try and open a PR for this tomorrow.

And sorry for the slow turnaround time here, @ldc2726 - I'm hoping to revisit this tomorrow!

[joffreyvillard]

Thanks for your reply @nfriend!

I'm using semantic-release/gitlab via the aplyca/semantic-release Docker image (https://hub.docker.com/r/aplyca/semantic-release) which is 8 months old, and embeds semantic-release version 17.4.4 (weirdly enough, the logs say 17.1.2) and @semantic-release/gitlab version 6.1.0

I guess I could start by building that image myself with the latest versions from npm.

[nfriend]

Just FYI, I opened a PR to add better logging: #245. Once this is merged, hopefully it will be a little easier to debug the root issue from the logs.

[joffreyvillard]

I can confirm that it works well on my side with the latest version (using node:alpine image + npm install -g semantic-release @semantic-release/gitlab ... instead of aplyca/semantic-release) - don't get why the npm view commands run within a container using that last image were indicating that the last version was in use 🤷

Thanks again for your prompt replies and the suggested/ongoing improvements

[nfriend]

@joffreyvillard Awesome, glad to hear it!

[EvanCarroll]

@joffreyvillard that's because npm view shows you the version on the repo, not the version you have installed. You want

/ # npm list -g semantic-release @semantic-release/gitlab 
/usr/local/lib
+-- @semantic-release/[email protected]
| `-- [email protected] deduped
`-- [email protected]
  +-- @semantic-release/[email protected]
  | `-- [email protected] deduped
  +-- @semantic-release/[email protected]
  | `-- [email protected] deduped
  +-- @semantic-release/[email protected]
  | `-- [email protected] deduped
  `-- @semantic-release/[email protected]
    `-- [email protected] deduped

That said, I can still get this issue. It may be worth nothing that this is also the error returned when your package name does not meet the naming convention

[EvanCarroll]

I also don't think @joffreyvillard and @ldc2726's issues are the same. @joffreyvillard pasted an error with a 404. This issue isolates error 400.

[nfriend]

Thanks everyone for the discussion!

It's been determined the root cause of this specific 400 error is an outdated GitLab version (v11) - see this comment above. We've decided not to fix this issue to minimize the maintenance burden of this plugin and stay consistent with this plugin's compatibility guidelines. More information about this decision here.

I'm going to go ahead and close this issue. However, please feel free to open a new issue if you are still seeing 400 errors on GitLab version 12 or later.

As a side note, errors like this should be easier to debug in the latest version of @semantic-release/gitlab since it now prints out more debug information (see #245).