potential publish failure recovery improvement

[semantic-release]

potential publish failure recovery improvement

[pvdlg]

The problem happen when we execute the command line npm publish ./. --registry https://registry.npmjs.org/

As this issue seems to happen more often recently it would be a good idea to open an issue with npm.
Would anyone involved in this thread want to open this issue?

Regarding the proposal to allow to finish the release after such issue, I'm not sure that would be possible, as any plugin can be used and they can depends on each other.
That said as we now separate the prepare and publish step we could assume that all preparation task are done in prepare therefore the publish could be considered independent of each other. So we could run all the publish task even if one of them fails.
I'm not sure if there is cases in which we would make the situation worst by doing so. So we need to think that through.

[jourdain]

NPM related issue

[pvdlg]

Thanks for raising the issue!
We trying to verify as much things as we can, catch the errors and display helpful. As the release process is quite sensitive I think it's ok for us to go the extra mile and be extra careful.

However we have to set a limit for which third-party shortcoming we handle, otherwise semantic-release will end up being a pile of workarounds on top of each other, which would make the code less stable and harder to maintain.

We had a similar issue with the GitHub plugin regarding throttling (to avoid going above the API limit) and request retries (as the API sometimes returns errors that it shouldn't and works on the second try).
Those issues should be handled by the GitHub API backend or by the GitHub client.

We implemented a basic version of throttling/retry in the GitHub plugin as a temporary solution, until it gets handled by the GitHub API client, but that quite an exception case.

In the case you are reporting, I think it should be handled in the npm registry backend if possible or in the npm CLI.

As a general rule, we can implement a workaround in semantic-release only if:

• The problem happens often and impact a lot of users
• The service that has the problem/short-coming cannot implement a solution in a timely fashion

So in the case you are reporting, it doesn't seems it's happening very often, and in any case it is a problem that should be reported to npm first (it seems to be a registry issue that return an invalid JSON response).

[travi]

totally fair. i mainly wanted to give a little visibility in case its helpful later on. totally fine if its not worth spending effort on, especially since i've only seen it once. this was more of a question of if it would be worth handling the rare situation where it (not necessarily just this particular error) does get past npm. your answer is where i expected to be and i think is very reasonable. i probably wont even send a report to the npm team with seeing it once since i'd be really surprised if they arent already on top of it.

[jourdain]

Adding the NPM error that I'm getting just so you can see what is happening.

It does not happen a lot but time to time it does fail. Below is the list of release tag missing on Github for vtk.js:

• 6.3.8
• 6.3.5
• 6.3.3
• 6.3.2
• 6.2.10
• 6.2.8

Without managing third-party flickyness, would it make sense to allow user to manually finish the release process? Several ideas below:

• print changelog that was not published when failing, so it could be copy/pasted
• query semantic release like git semantic-release --changelog 6.3.7..HEAD or else.
• ask semantic release to finish a task semantic-release --publish 6.3.8 (might be tricky since you may not have relationship between npm version and git/sha)

Anyway, thanks a lot for that awesome tool that save us so much time!!!

[Semantic release]: The release type for the commit is patch
[Semantic release]: Analysis of 10 commits complete: patch release
[Semantic release]: The next release version is 6.3.8
[Semantic release]: Call plugin verify-release
[Semantic release]: Call plugin generateNotes
[Semantic release]: Call plugin publish
[Semantic release]: Wrote version 6.3.8 to package.json
[Semantic release]: Publishing version 6.3.8 to npm registry
[Semantic release]: An error occurred while running semantic-release: { Error: Command failed: npm publish ./. --registry https://registry.npmjs.org/
npm ERR! registry error parsing json
npm ERR! registry error parsing json
npm ERR! registry error parsing json
npm ERR! publish Failed PUT 504
npm ERR! Unexpected token < in JSON at position 0
npm ERR! <html><body><h1>504 Gateway Time-out</h1>
npm ERR! The server didn't respond in time.
npm ERR! </body></html>
npm ERR! 
npm ERR! 
npm ERR! A complete log of this run can be found in:
npm ERR!     /home/travis/.npm/_logs/2018-03-07T00_29_15_789Z-debug.log
    at Promise.all.then.arr (/home/travis/build/Kitware/vtk-js/node_modules/execa/index.js:236:11)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:188:7)
  code: 1,
  killed: false,
  stdout: '',
  stderr: 'npm ERR! registry error parsing json\nnpm ERR! registry error parsing json\nnpm ERR! registry error parsing json\nnpm ERR! publish Failed PUT 504\nnpm ERR! Unexpected token < in JSON at position 0\nnpm ERR! <html><body><h1>504 Gateway Time-out</h1>\nnpm ERR! The server didn\'t respond in time.\nnpm ERR! </body></html>\nnpm ERR! \nnpm ERR! \n\nnpm ERR! A complete log of this run can be found in:\nnpm ERR!     /home/travis/.npm/_logs/2018-03-07T00_29_15_789Z-debug.log\n',
  failed: true,
  signal: null,
  cmd: 'npm publish ./. --registry https://registry.npmjs.org/',
  timedOut: false }
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] semantic-release: `semantic-release`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the [email protected] semantic-release script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! A complete log of this run can be found in:
npm ERR!     /home/travis/.npm/_logs/2018-03-07T00_29_15_827Z-debug.log

[jourdain]

I agree and I let you judge on what is the best option going forward. But during that prepare phase if we could have a verbose output option, that would let us copy/paste the changelog text to any missing publish. I'll add a report to npm and crosslink it once it is done.

Thanks!