400 "Missing 'name' parameter" when adding a release asset #2132

pbrisbin commented 2025年09月11日 21:25:08 +02:00

Comment

I'm trying to use @semantic-release/github to auto-release to Codeberg releases. It works when there are no release assets, but when there are assets, it gets a 400 from the POST /repos/{owner}/{repo}/releases/{id}/assets endpoint, saying Missing 'name' parameter.

The code that performs this API call is here, and the details dumped in the error message are:

...: RequestError [HttpError]: Missing 'name' parameter
...
{
 status: 400,
 request: {
 method: 'POST',
 url: 'https://codeberg.org/api/v1/repos/pbrisbin/man-pages-lint/releases/4573864/assets',
 headers: {
 accept: 'application/vnd.github.v3+json',
 'user-agent': '@semantic-release/github v11.0.0 octokit-core.js/6.1.2 Node.js/20.19.5 (linux; x64)',
 'content-type': 'application/gzip',
 'content-length': 1358651,
 authorization: 'token [REDACTED]'
 },
 body: <Buffer 1f 8b 08 00 00 00 00 00 00 03 e4 dc 0b 74 1c d5 79 07 f0 6b d9 92 e5 17 16 7e 0a 63 83 30 d8 08 83 a5 5d 3d d7 e6 b5 18 83 65 83 41 18 1b 1c a0 ac 67 ... 1358601 more bytes>,
 request: { agent: undefined, hook: [Function: bound bound register] }
 },
 response: {
 url: 'https://codeberg.org/api/v1/repos/pbrisbin/man-pages-lint/releases/4573864/assets',
 status: 400,
 headers: {
 'alt-svc': 'h3=":443"; ma=2592000,h3=":443"; ma=2592000',
 'cache-control': 'max-age=0, private, must-revalidate, no-transform',
 connection: 'close',
 'content-length': '80',
 'content-type': 'application/json;charset=utf-8',
 date: '2025年9月11日 19:08:28 GMT',
 'permissions-policy': 'interest-cohort=()',
 'strict-transport-security': 'max-age=63072000; includeSubDomains; preload',
 vary: 'Origin',
 via: '1.1 Caddy',
 'x-content-type-options': 'nosniff',
 'x-frame-options': 'SAMEORIGIN'
 },
 data: {
 message: "Missing 'name' parameter",
 url: 'https://codeberg.org/api/swagger'
 }
 },
 pluginName: '@semantic-release/github'
}
::error::HttpError: Missing 'name' parameter

I'm shocked getting a GitHub plugin to talk to a Forgejo API works as well as it does, so I'm not at all surprised there is some kind of mismatch here, but I'm unclear on what to do about it. The Swagger spec for this endpoint shows name as optional.

The Pull Request where I'm trying this out is here.

• .releaserc.yaml configuration
• release.yml workflow
• Most recent attempt at time of writing is here

### Comment I'm trying to use `@semantic-release/github` to auto-release to Codeberg releases. It works when there are no release assets, but when there are assets, it gets a 400 from the `POST /repos/{owner}/{repo}/releases/{id}/assets` endpoint, saying `Missing 'name' parameter`. The code that performs this API call is [here](https://github.com/semantic-release/github/blob/ed9069805ceb823c65d4b674614e5e320138bb1f/lib/publish.js#L131-L152), and the details dumped in the error message are: ``` ...: RequestError [HttpError]: Missing 'name' parameter ... { status: 400, request: { method: 'POST', url: 'https://codeberg.org/api/v1/repos/pbrisbin/man-pages-lint/releases/4573864/assets', headers: { accept: 'application/vnd.github.v3+json', 'user-agent': '@semantic-release/github v11.0.0 octokit-core.js/6.1.2 Node.js/20.19.5 (linux; x64)', 'content-type': 'application/gzip', 'content-length': 1358651, authorization: 'token [REDACTED]' }, body: <Buffer 1f 8b 08 00 00 00 00 00 00 03 e4 dc 0b 74 1c d5 79 07 f0 6b d9 92 e5 17 16 7e 0a 63 83 30 d8 08 83 a5 5d 3d d7 e6 b5 18 83 65 83 41 18 1b 1c a0 ac 67 ... 1358601 more bytes>, request: { agent: undefined, hook: [Function: bound bound register] } }, response: { url: 'https://codeberg.org/api/v1/repos/pbrisbin/man-pages-lint/releases/4573864/assets', status: 400, headers: { 'alt-svc': 'h3=":443"; ma=2592000,h3=":443"; ma=2592000', 'cache-control': 'max-age=0, private, must-revalidate, no-transform', connection: 'close', 'content-length': '80', 'content-type': 'application/json;charset=utf-8', date: '2025年9月11日 19:08:28 GMT', 'permissions-policy': 'interest-cohort=()', 'strict-transport-security': 'max-age=63072000; includeSubDomains; preload', vary: 'Origin', via: '1.1 Caddy', 'x-content-type-options': 'nosniff', 'x-frame-options': 'SAMEORIGIN' }, data: { message: "Missing 'name' parameter", url: 'https://codeberg.org/api/swagger' } }, pluginName: '@semantic-release/github' } ::error::HttpError: Missing 'name' parameter ``` I'm shocked getting a GitHub plugin to talk to a Forgejo API works as well as it does, so I'm not at all surprised there is some kind of mismatch here, but I'm unclear on what to do about it. The Swagger spec for this endpoint shows `name` as optional. The Pull Request where I'm trying this out is [here](https://codeberg.org/pbrisbin/man-pages-lint/pulls/3). - [.releaserc.yaml](https://codeberg.org/pbrisbin/man-pages-lint/src/branch/rc/semantic-release/.releaserc.yaml) configuration - [release.yml](https://codeberg.org/pbrisbin/man-pages-lint/src/branch/rc/semantic-release/.forgejo/workflows/release.yml) workflow - Most recent attempt at time of writing is [here](https://codeberg.org/pbrisbin/man-pages-lint/actions/runs/24)

pbrisbin commented 2025年09月11日 22:24:45 +02:00

Interestingly, the docs for the GitHub API say name is required. So I'm not sure how this plugin works against GitHub, if there are cases where it's not including it. I now suspect it's an issue on my side; I'll continue investigating.

Interestingly, the docs for the GitHub API say `name` is required. So I'm not sure how this plugin works against GitHub, if there are cases where it's not including it. I now suspect it's an issue on my side; I'll continue investigating.

pbrisbin commented 2025年09月11日 22:46:33 +02:00

OK, I think I see why.

With GitHub, the create-release endpoint returns an upload_url like:

"https://uploads.github.com/repos/octocat/Hello-World/releases/1/assets{?name,label}"

But with Forgejo, I'm getting,

"https://codeberg.org/api/v1/repos/pbrisbin/man-pages-lint/releases/4574527/assets"

(There is no {?name,label} part.)

I believe this means that, when upload_url is used by the SDK, it drops the name (and label) data, so we get the 400.

Is this a bug?

OK, I think I see why. With GitHub, the [create-release endpoint](https://docs.github.com/en/rest/releases/releases?apiVersion=2022年11月28日#create-a-release) returns an `upload_url` like: ``` "https://uploads.github.com/repos/octocat/Hello-World/releases/1/assets{?name,label}" ``` But with Forgejo, I'm getting, ``` "https://codeberg.org/api/v1/repos/pbrisbin/man-pages-lint/releases/4574527/assets" ``` (There is no `{?name,label}` part.) I believe this means that, when `upload_url` is used by the SDK, it drops the `name` (and `label`) data, so we get the 400. Is this a bug?

Gusted commented 2025年09月11日 23:00:10 +02:00

@pbrisbin wrote in #2132 (comment):

Is this a bug?

The API has no guarantee that it matches the Github API. So not a bug.

@pbrisbin wrote in https://codeberg.org/Codeberg/Community/issues/2132#issuecomment-7119301: > Is this a bug? The API has no guarantee that it matches the Github API. So not a bug.

pbrisbin commented 2025年09月11日 23:33:14 +02:00

Definitely fair, but it seems to have the same intention to use a Hypermedia relation for this functionality. It not doing so correctly could still be a bug. It just happens that GitHub is a good example for it being done correctly.

In other words, if you're meant to take the upload_url from creating a release and use it to upload any assets to that release, and the upload-assets endpoint does require name (which the error indicates), then the upload_url not including a name template is a bug.

If you're not meant to (and in fact can't) use the upload_url, why have it in the response at all -- if not to match the GitHub API?

Definitely fair, but it seems to have the same intention to use a Hypermedia relation for this functionality. It not doing so correctly could still be a bug. It just happens that GitHub is a good example for it being done correctly. In other words, if you're meant to take the `upload_url` from creating a release and use it to upload any assets to that release, and the upload-assets endpoint does require `name` (which the error indicates), then the `upload_url` not including a `name` template is a bug. If you're not meant to (and in fact can't) use the `upload_url`, why have it in the response at all -- if not to match the GitHub API?

Gusted commented 2025年09月13日 17:40:22 +02:00

@pbrisbin wrote in #2132 (comment):

In other words, if you're meant to take the upload_url from creating a release and use it to upload any assets to that release, and the upload-assets endpoint does require name (which the error indicates), then the upload_url not including a name template is a bug.

No? This is not how any of the other responses are formatted. It will be nice to have for sure, but adding this retrospectively will cause API breakage.

@pbrisbin wrote in #2132 (comment):

If you're not meant to (and in fact can't) use the upload_url, why have it in the response at all -- if not to match the GitHub API?

It does look like the field was added to match the Github API (by me, oops) in forgejo/forgejo#929 but that was for a different release action https://github.com/softprops/action-gh-release. @earl-warren do you happen to know if that release action required the templates or not?

@pbrisbin wrote in https://codeberg.org/Codeberg/Community/issues/2132#issuecomment-7119715: > In other words, if you're meant to take the `upload_url` from creating a release and use it to upload any assets to that release, and the upload-assets endpoint does require `name` (which the error indicates), then the `upload_url` not including a `name` template is a bug. No? This is not how any of the other responses are formatted. It will be nice to have for sure, but adding this retrospectively will cause API breakage. @pbrisbin wrote in https://codeberg.org/Codeberg/Community/issues/2132#issuecomment-7119715: > If you're not meant to (and in fact can't) use the `upload_url`, why have it in the response at all -- if not to match the GitHub API? It does look like the field was added to match the Github API (by me, oops) in https://codeberg.org/forgejo/forgejo/pulls/929 but that was for a different release action https://github.com/softprops/action-gh-release. @earl-warren do you happen to know if that release action required the templates or not?

pbrisbin commented 2025年09月13日 18:58:30 +02:00

you're meant to take the upload_url from creating a release and use it to upload any assets to that release

No?

What are you meant to do with it?

This is not how any of the other responses are formatted

You're just saying that the Forgejo API does not make use of Hypermedia relations anywhere? That's too bad, they're a useful spec/feature IMO.

It will be nice to have for sure, but adding this retrospectively will cause API breakage.

We agree.

do you happen to know if that release action required the templates or not?

This action just discards the template portion,

softprops/action-gh-release@19cd0bcd2b/src/util.ts (L27)

export const uploadUrl = (url: string): string => {
 const templateMarkerPos = url.indexOf('{');
 if (templateMarkerPos > -1) {
 return url.substring(0, templateMarkerPos);
 }
 return url;
};

Then appends a name itself:

softprops/action-gh-release@19cd0bcd2b/src/github.ts (L174-L175)

 const endpoint = new URL(url);
 endpoint.searchParams.append('name', name);

This is pretty sketchy stuff (and also unnecessary, if the action had just handed the templated URL to the Oktokit client with a name argument it would've Just Worked, like semantic-release/github does), but would function against upload_urls with and without the template suffix. Does that mean the breakage from implementing the template may not be so bad?

> > you're meant to take the `upload_url` from creating a release and use it to upload any assets to that release > > No? What _are_ you meant to do with it? > This is not how any of the other responses are formatted You're just saying that the Forgejo API does not make use of Hypermedia relations anywhere? That's too bad, they're a useful spec/feature IMO. > It will be nice to have for sure, but adding this retrospectively will cause API breakage. We agree. > do you happen to know if that release action required the templates or not? This action just discards the template portion, https://github.com/softprops/action-gh-release/blob/19cd0bcd2b95a5f9e0aab8377b3cae33e51c2234/src/util.ts#L27 ```js export const uploadUrl = (url: string): string => { const templateMarkerPos = url.indexOf('{'); if (templateMarkerPos > -1) { return url.substring(0, templateMarkerPos); } return url; }; ``` Then appends a `name` itself: https://github.com/softprops/action-gh-release/blob/19cd0bcd2b95a5f9e0aab8377b3cae33e51c2234/src/github.ts#L174-L175 ```js const endpoint = new URL(url); endpoint.searchParams.append('name', name); ``` This is pretty sketchy stuff (and also unnecessary, if the action had just handed the templated URL to the Oktokit client with a `name` argument it would've Just Worked, like semantic-release/github does), but would function against `upload_url`s with and without the template suffix. Does that mean the breakage from implementing the template may not be so bad?

Gusted commented 2025年09月13日 21:46:04 +02:00

I'll make a PR to update the URL in that case.

I'll make a PR to update the URL in that case.