Release fails when adding "release" labels. Error 422.

[Aghassi]

Release fails when adding "release" labels. Error 422.

[Aghassi]

For now, what I have gone and done is the following in package.json and updated my yarn.lock

  "resolutions": {
    "semantic-release/@semantic-release/github": "5.2.1"
  },

Not a perfect solution, but it unblocks us until this stuff is figured out. It is interesting because even though I specified that version as a devDependency, semantic-release brings it's own in which is a ^ semver and grabs the latest, which is breaking. Also interesting is that it doesn't use the one I provide, it uses the one it brings in. So even though I thought that I had a pinned version, I really didn't.

[pvdlg]

I just added 5.2.7 to @latest

[gr2m]

Is this running against GitHub enterprise?

The endpoint to add labels was recently changed. Instead of accepting labels as array in the request body, they are now sent with a "labels" namespace. The change breaks usage with GitHub enterprise, I don’t think they will backport that fix.

I’m not sure how to address this :/ we could workaround it in @semantic-release/github by not using the octokit.issues.addLabels() API, but instead use ocotkit.request('POST /repos/:owner/:repo/issues/:number/labels', {data: ['released']})

For reference

• add labels on dotcom: https://developer.github.com/v3/issues/labels/#add-labels-to-an-issue
• add labels on latest GHE: https://developer.github.com/enterprise/2.15/v3/issues/labels/#add-labels-to-an-issue

[Aghassi]

@gr2m Yes this is Github Enterprise. Version 2.12. We are moving to 2.14 tomorrow apparently. The odd thing is that other repos with this same setup are not experiencing this issue. It is sort of hit or miss depending on what yarn resolves I think.

[Aghassi]

@gr2m one thought I would have is can you check the version of GHE you are hitting? If below a certain version fallback?

[pvdlg]

@gr2m it seems that @octokit/rest.js version 16.0.0 has a minimum version requirement for the GitHub enterprise API version. Is the old version (the one that expect labels as an Array and not an object) of the GitHub Enterprise deprecated?
If it's not deprecated by GitHub, shouldn't @octokit/rest.js support it? Like, I would assume the latest version of @octokit/rest.js to work with every version of the API that GitHub consider supported/not deprecated.

[gr2m]

it seems that @octokit/rest.js version 16.0.0 has a minimum version requirement for the GitHub enterprise API version.

The idea of a GHE requirement is something we started to discuss with the Octokit maintainers across the supported languages, we don’t have a conclusion yet.

Is the old version (the one that expect labels as an Array and not an object) of the GitHub Enterprise deprecated?

No the GHE version is still supported

If it's not deprecated by GitHub, shouldn't @octokit/rest.js support it? Like, I would assume the latest version of @octokit/rest.js to work with every version of the API that GitHub consider supported/not deprecated.

Yes, you are right, sorry for the trouble :(

The approach I am taking is that you will be able to load the endpoint methods for a certain enterprise version, which will still work on api.github.com. I only created a plugin for enterprise endpoints this week: https://github.com/octokit/plugin-enterprise-rest.js.

In theory, we should be able to do this:

const Octokit = require('@octokit/rest')
  .plugin(require('@octokit/enterprise-rest/v2.15'))
const octokit = new Octokit({
  baseUrl: 'https://github.acme-inc.com/api/v3'
})

and it will override methods such as .issues.addLabels(). This should all be working, but to be honest I haven’t tested it myself yet. But I can do that now and maybe that’s what we can do?

[pvdlg]

So that mean the @octokit/rest user will have to specify the plugin in order to support the "old" enterprise endpoint?

Shouldn't @octokit/rest just work with any version of the API officially supported? It seems weird to require @octokit/rest users to know about every changes in the enterprise API endpoint.

It's probably a good idea to use a plugin internally to support both the old and new endpoint but I don't think it should have to be defined by the @octokit/rest user. As an @octokit/rest user I don't see myself subscribing to the GitHub changelog and adding/removing plugins in my code every time an endpoint is updated, or an old one becomes unsupported.

Maybe the solution is an internal/default plugin that would be called on errors and:

• Read the API version from the header
• If the current call is made to and "old" endpoint, then convert the input to the old format and re-do the call
• If the error is not related to an endpoint change then throw it

This plugin would have to maintain a list of data transform to insure the compatibility with old endpoint that are not deprecated yet.

[gr2m]

I mean that semantic-release can use require('@octokit/enterprise-rest/v2.15') or what ever enterprise version you want to support. I’m aware of the shortcomings of @octokit/rest & enterprise support, we will get there eventually, there is still lots of work ahead. We will probably setup LTS versions that match with respective enterprise versions, not sure yet

[pvdlg]

The thing is I don't know which version I want to support, because I don't know which version of GHE are supported, and what each version deprecate and change. I just want to support all versions that GitHub support.

For now semantic-release users have to specify @semantic-release/[email protected] in their package.json as it's the last version that uses @octokit/rest.js@15. See #138 (comment).
That's not sustainable because @semantic-release/[email protected] will not be compatible with @[email protected]. Plus those users won't get any fix released after @semantic-release/[email protected].

If for now supporting all version of GHE supported by GitHub means reverting to @octokit/rest.js@15 I think that's fine. We can revert to that version and migrate to @octokit/rest.js@16 once a solution is implemented.

[gr2m]

I just want to support all versions that GitHub support.

It's not that simple, GitHub is adding new APIs all the time and people want to use it. But these new APIs won’t work on GitHub Enterprise. So in the end you will have to decide which GitHub versions you want to support and pick the right Octokit version that supports the GitHub Enterprise version you need. Hence the LTS approach, we will have maintenance versions that we will keep supporting as long as the respective enterprise versions are supported

[pvdlg]

So that mean in @semantic-release/github we have to choose which we support and we can't have the plugin working for everyone?

For @semantic-release/github I think it's more important to support as many users as possible rather than using the last API. The last API doesn't bring any advantage as far as I can tell which is why I proposed to go back to @octokit/rest.js@15. But maybe I'm wrong to assume it would make @semantic-release/github work for everyone again.

Anyway, you have a better understanding of the situation than me, so you know what's the best solution!

[gr2m]

Here is a PR implementing the workaround using ocotkit.request(): #140

That’s the simplest fix right now

[pvdlg]

👍If you think that's the best for now, let's go with that!

[semantic-release-bot]

🎉 This issue has been resolved in version 5.2.7 🎉

The release is available on:

• npm package (@next dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[Aghassi]

Thank you both for taking the time to address this! I'm happy to work with you guys on GHE support long term as we use it. However, moving to 2.14 may change some things so who knows how much use that will be in the future.

[Aghassi]

@pvdlg Just wanted to clarify. It seems it was published to the next tag in NPM. How often does next move to latest?