Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

An error occurred while running semantic-release: HTTPError: Response code 400 (Bad Request) #158

Closed
digitaltopo opened this issue Aug 6, 2020 · 8 comments · Fixed by #179

Comments

@digitaltopo
Copy link

Seeing a HTTPError: Response code 400 (Bad Request) error in the GitLab pipeline job:

 [9:56:02 PM] [semantic-release] › ✖  Failed step "publish" of plugin "@semantic-release/gitlab"
 [9:56:02 PM] [semantic-release] › ✖  An error occurred while running semantic-release: HTTPError: Response code 400 (Bad Request)
     at EventEmitter.<anonymous> (/builds/code/path/to/lib/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 400 (Bad Request)
     at EventEmitter.<anonymous> (/builds/code/path/to/lib/node_modules/got/dist/source/as-promise.js:118:31)
     at processTicksAndRejections (internal/process/task_queues.js:93:5) {
   pluginName: '@semantic-release/gitlab'
 }
 ERROR: Job failed: exit code 1

I belive error is triggered from publish.js file in semantic-release/gitlab:
https://github.com/semantic-release/gitlab/blob/8477d146c47d9c515ae12bb98949fc535a84435d/lib/publish.js

Project's .releaserc looks like this:

{
  "repositoryUrl": ...,
  "branches": [
    "master",
    "next"
  ],
  "prepare": [
    "@semantic-release/changelog",
    "@semantic-release/npm",
    {
      "path": "@semantic-release/git",
      "assets": [
        "package.json",
        "package-lock.json",
        "CHANGELOG.md"
      ],
      "message": "chore(release): ${nextRelease.version} [skip ci]nn${nextRelease.notes}"
    }
  ],
  "plugins": [
    "@semantic-release/commit-analyzer",
    "@semantic-release/release-notes-generator",
    "@semantic-release/changelog",
    [
      "@semantic-release/npm",
      {
        "npmPublish": true,
        "pkgRoot": "./lib"
      }
    ],
    [
      "@semantic-release/git",
      {
        "assets": [
          "package.json",
          "CHANGELOG.md"
        ],
        "message": "chore(release): ${nextRelease.version} [skip ci]\n\n${nextRelease.notes}"
      }
    ],
    [
      "@semantic-release/gitlab",
      {
        "assets": [
          {
            "path": [
              "lib/**/*.js"
            ],
            "label": "JS distribution"
          }
        ]
      }
    ]
  ]
}

In GitLab, I've set: GL_TOKEN, GL_URL, and GL_PREFIX 

Any thoughts on what could be causing this? Thank you!

@paulfelton
Copy link

I'm getting the same error. I can't see much debug information to see what's happening. I note that the release does actually happen, although the assets look to be a very small subset of what I'd expect, so maybe it's related to that?

@MathieuPuech
Copy link

I tried to get the error with a try catch with got but I didn't get what was the error. To fix it I used ky-universal instead. I can create a PR for this if you want.

@yyellowsun
Copy link

I use the github actions and meet the same problem.
But I modify the GITHUB_TOKEN,and solve the problem.
Maybe useful to you.

@nfriend
Copy link
Contributor

nfriend commented Nov 24, 2020

Just ran into this as well! Did a little investigation and found the root cause. This happens when assets.path matches more than one file, for example:

{
  "plugins": [
    [
      "@semantic-release/gitlab",
      {
        "assets": [
          { "path": "build/**/*", "label": "Compiled files" }
        ]
      }
    ]
  ]
}

GitLab's release links must have both a unique name and URL (within a given release). In the example above, semantic-release/gitlab attempts to upload all files that match build/**/* with the same name ("Compiled files"). As a result, only the first request will succeed, causing the subset behavior mentioned in the comment above.

An immediate workaround is to not use glob patterns in asset.path and instead list each file individually (with a unique name).

A more long-term solution would be to update this module to either:

  1. Attached a suffix to files with duplicate names ("Compiled files 1", Compiled files 2", "Compiled files 3", etc.), or
  2. Combine the files into a .zip (when a glob pattern is provided) and upload the .zip as a single file

I think #2 would be the more elegant solution. I'll look into this and open a PR if this seem doable.

As a side note, I've put together an MR to add a note about release links' uniqueness constraints: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/48484/diffs.

@nfriend
Copy link
Contributor

nfriend commented Nov 24, 2020

Actually, this module does already account for the validation issue I mentioned above - it just wasn't working quite right.

I've submitted #179 which fixes this 👍 Now, if a path glob pattern matches more than one file, the file name will be used as the label (and the label property will be ignored). This makes the possibility of a label collision less likely.

@nfriend
Copy link
Contributor

nfriend commented Nov 24, 2020

An immediate workaround is to not use glob patterns in asset.path and instead list each file individually (with a unique name).

Found another even simpler workaround: remove the label property for any patterns that match more than one file. In this case, this module will fall back to creating each item with its label set to the file's name.

@travi travi closed this as completed in #179 Dec 1, 2020
EvanCarroll added a commit to EvanCarroll/gitlab that referenced this issue Jul 29, 2021
Previously GitLab lables were just the basename for files uploaded as
part of the release. This is problematic because GitLab doesn't allow
conflicting labels -- a condition that could be caused by uploading a
release with two files by the same name in different directories. This
would generate a 409 Conflict error.

This patches changes the labels for files uploaded as part of a release
to the name relative to pkgRoot, or the package.

A project may look like this

  pkg
  pkg \ foo \ baz
  pkg \ bar \ baz

This used to creating two conflicting labels of 'baz'. Now you would
have {"foo/baz", "bar/baz"} with no conflict.

GitHub issues: semantic-release#263, semantic-release#158
EvanCarroll added a commit to EvanCarroll/gitlab that referenced this issue Jul 29, 2021
Previously GitLab lables were just the basename for files uploaded as
part of the release. This is problematic because GitLab doesn't allow
conflicting labels -- a condition that could be caused by uploading a
release with two files by the same name in different directories. This
would generate a 409 Conflict error.

This patches changes the labels for files uploaded as part of a release
to the name relative to pkgRoot, or the package.

A project may look like this

  pkg
  pkg \ foo \ baz
  pkg \ bar \ baz

This used to creating two conflicting labels of 'baz'. Now you would
have {"foo/baz", "bar/baz"} with no conflict.

GitHub issues: semantic-release#263, semantic-release#158
EvanCarroll added a commit to EvanCarroll/gitlab that referenced this issue Jul 29, 2021
Previously GitLab lables were just the basename for files uploaded as
part of the release. This is problematic because GitLab doesn't allow
conflicting labels -- a condition that could be caused by uploading a
release with two files by the same name in different directories. This
would generate a 409 Conflict error.

This patches changes the labels for files uploaded as part of a release
to the name relative to pkgRoot, or the package.

A project may look like this

  pkg
  pkg \ foo \ baz
  pkg \ bar \ baz

This used to creating two conflicting labels of 'baz'. Now you would
have {"foo/baz", "bar/baz"} with no conflict.

GitHub issues: semantic-release#263, semantic-release#158
EvanCarroll added a commit to EvanCarroll/gitlab that referenced this issue Jul 29, 2021
Previously GitLab lables were just the basename for files uploaded as
part of the release. This is problematic because GitLab doesn't allow
conflicting labels -- a condition that could be caused by uploading a
release with two files by the same name in different directories. This
would generate a 409 Conflict error.

This changes the labels for files uploaded as part of a release to the
name relative to pkgRoot, or the package.

A project may look like this

  pkg
  pkg \ foo \ baz
  pkg \ bar \ baz

This would previously result in two conflicting labels of 'baz'. Now you
would have {"foo/baz", "bar/baz"} with no conflict.

GitHub issues: semantic-release#263, semantic-release#158
EvanCarroll added a commit to EvanCarroll/gitlab that referenced this issue Jul 29, 2021
Previously GitLab lables were just the basename for files uploaded as
part of the release. This is problematic because GitLab doesn't allow
conflicting labels -- a condition that could be caused by uploading a
release with two files by the same name in different directories. This
would generate a 409 Conflict error.

This changes the labels for files uploaded as part of a release to the
name relative to pkgRoot, or the package.

A project may look like this

  pkg
  pkg \ foo \ baz
  pkg \ bar \ baz

This would previously result in two conflicting labels of 'baz'. Now you
would have {"foo/baz", "bar/baz"} with no conflict.

GitHub issues: semantic-release#265, semantic-release#158
EvanCarroll added a commit to EvanCarroll/gitlab that referenced this issue Sep 24, 2021
Previously GitLab lables were just the basename for files uploaded as
part of the release. This is problematic because GitLab doesn't allow
conflicting labels -- a condition that could be caused by uploading a
release with two files by the same name in different directories. This
would generate a 409 Conflict error.

This changes the labels for files uploaded as part of a release to the
name relative to pkgRoot, or the package.

A project may look like this

  pkg
  pkg \ foo \ baz
  pkg \ bar \ baz

This would previously result in two conflicting labels of 'baz'. Now you
would have {"foo/baz", "bar/baz"} with no conflict.

GitHub issues: semantic-release#265, semantic-release#158
@desprit
Copy link

desprit commented Jan 5, 2022

@nfriend

I'm struggling with the same issue. Could you take a look, please?

My dist folder after build step has the following structure:

...              
dist/index.d.ts                                                                
dist/stories/shared/Button.stories.d.ts                                        
dist/stories/shared/Pill.stories.d.ts                                          
dist/stories/shared/TextInput.stories.d.ts                                     
dist/stories/worklist/components/GlobalFilter.stories.d.ts                     
dist/stories/worklist/components/TableFilters.stories.d.ts                     
dist/stories/worklist/components/TableMeta.stories.d.ts                        
dist/stories/worklist/mocks.d.ts                                               
dist/stories/worklist/Worklist.stories.d.ts                                    
dist/style.css                                                                 
dist/mylib.es.js                                                            
dist/mylib.es.js.map                                                        
dist/mylib.umd.js                                                           
dist/mylib.umd.js.map
...

I'm receiving the following error:

An error occurred while making a request to the GitLab release API

If I disable generation of declaration files release works good. Is it not possible to have directories in the dist? Or is it due to something else?
One more thing that I noticed is this:

...
[@semantic-release/gitlab] › ℹ  Uploaded file: /uploads/745a6ca949aafd18a252a04eee870e81/TextInput.stories.d.ts
[@semantic-release/gitlab] › ℹ  Uploaded file: /uploads/8e7eebbd2230ee9bf3ca1bf6bafbaa18/AiProcessing.vue.d.ts
[@semantic-release/gitlab] › ℹ  Uploaded file: /uploads/f4251a970929d78e5e8f6e0a29b8b67d/GlobalFilter.vue.d.ts
[@semantic-release/gitlab] › ℹ  Uploaded file: /uploads/a5be6bc7d392fb71fc6fdf631f36039b/TableMeta.stories.d.ts
...

which means that even with source filename collisions the final filenames are unique? I really wish there was more info in the error message...

@damdafayton
Copy link

i still have the same error with
"@semantic-release/gitlab": "^13.0.2", and "semantic-release": "^23.0.0"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants