More automated release fixes

[blink1073]

References

Follow up to #10614

Code changes

Use the already-packaged files from the npm build phase to publish to verdaccio, to ensure that the shasum of the package is the same as the one that gets published to npm in the publish workflow. The rc0 release broke because the packages that were published to verdaccio had a gitHead field in their package.json (added by lerna) while the ones published to npm did not, causing yarn to reject them based on checksum.

User-facing changes

None

Backwards-incompatible changes

None

[jupyterlab-dev-mode]

Thanks for making a pull request to JupyterLab!

To try out this branch on binder, follow this link:

[bollwyvl]

Hooray cryptographic assurance!

Indeed, generating a SHA256SUMS of automatically uploaded assets (nothing fancy, e.g. sha256sum * > SHA256SUMS) has become my favorite way to fully characterize CI-built releases.

[blink1073]

Jupyter Releaser adds those for us ;).

[bollwyvl]

Hm, that's mighty... fancy. And not a file that one can go look at in the release outputs, much less reproduce with bog-standard tooling.

[jasongrout]

And not a file that one can go look at in the release outputs, much less reproduce with bog-standard tooling.

Are you saying that you also want those hashes in a file somewhere?

The nice thing about having them in the git history is that is the one immutable place to put them that ties them back to a source. In other words, I have relatively high confidence that the git history is authentic, and since the release hash is in the git history, I have relatively high confidence that the tgz on my disk that has that hash is identical to what was originally generated. Of course, we could equivalently have a directory of release hash files in the git repo. Is that what you are suggesting?

[blink1073]

We can backport this to 3.1.x, but I won't do any more automated 3.1.x releases until we have made a couple 4.0 alpha releases using releaser.

[bollwyvl]

having them in the git history

... is awesome! but the lab git is... big. And doesn't actually contain those files.

As a sucker downstream, being able to predict a well-known file, e.g. firefox, miniforge (though it does one per installer) is super handy for automation purposes.

[jasongrout]

As a sucker downstream, being able to predict a well-known file, e.g. firefox, miniforge (though it does one per installer) is super handy for automation purposes.

I think we could have a releases directory in the repo, and in it are files named by release that contain the hashes. So for example, releases/3.1.0rc1.sha256 or something?

[blink1073]

@meeseeksdev please backport to 3.1.x