chore(ci): add individual publishing of packages MONGOSH-1871

[gagik]

This adds the ability to individually publish packages in mongosh. Also, notably, all packages's version inside package.json will now match the latest released version and update accordingly upon release.

Structure

Package Bumping

With this change, there are 2 types of package bumping depending on what package it is:

1. mongosh release-related packages bump
   mongosh and @mongosh/cli-repl are bumped only at mongosh release and have their versions synced.
   This gets triggered only during a mongosh release.
2. npm auxiliary packages bump
   All other packages are bumped independently of mongosh using bump-packages from monorepo-tools. Each package can have divergent versions as a result.
   This can be triggered anytime using GitHub actions which will create PR for bump package versions, merging of which will cause CI to publish the packages.

Individual Package Release

You can release an individual package by running a bump packages GitHub Action and merging the created PR.

mongosh Release

A mongosh release will cause both an npm package bump and a mongosh release bump before starting the release.

[gagik]

@addaleax Didn't get to spend too much time on this before my holiday with some VSCode and coverage test back and forths. Would be happy to jump back into it in a week but if it'd be better to finish this earlier, feel free to pick it up 🙂 I have some WIP files that I may polish up and push at a later time also though not sure how useful they are; will see.

[gagik]

The idea here is that this will bump both "independent" and mongosh packages before the release draft and push it to main, so our branch is consistent with what we're releasing.
It might also make sense to only persist this after the release is published.

I am assuming this should work? Though not sure if the evergreen git setup has ability to push to main like this?

[gagik]

ignoring these since these are private, unless it'd make sense to publish anyways?

[gagik]

these were all set to 2.3.7 manually to get the current repository consistent with the latest release

[nirinchev]

I know this is modeled after what we already have and I'm not opposed to merging it as-is. That being said, I'd prefer if we move to a different publishing model, where we run the publish packages workflow on the bump packages PR, merge that PR, and only then tag the versions on main. That way we would eliminate a case where we have versions committed in main that haven't been published due to a glitch somewhere.

Additionally, we should move the npm token to an environment secret, which will require approvals for the workflow to run.

[gagik]

@nirinchev Agree, wanted to ask before expanding the scope but I think it'd be a lot nicer and cleaner with this setup. I can clean that up and the documentation

[addaleax]

Just double-checking, on a mongosh release we're still publishing the full list of packages, right?

How does this interact with the GH action scripts for publishing independent packages? Do we just need to be careful not to trigger them while a release is pending?

[gagik]

Yeah I suppose that would be problematic if both happened at the same time. Perhaps if we move this to GitHub Actions we could also enforce that a Release action doesn't start if there's another Release aux. packages etc. one is running

[addaleax]

I don't know where we need to to leave this comment, so I'll leave it here – in shell-api.ts, we fetch the current mongosh version via require('../package.json').version. We should replace that with a new method on EvaluationListener that we then call from there, so that the mongosh CLI can provide the correct version to the shell-api package (and probably also add an e2e test that mongosh --eval 'version()' and mongosh --version print the same output).