Publish through GitHub actions

[jreineckearm]

Partly addresses #379

Notes:

• Flow is not tested yet. Could make sense to make a test publish with current next version after merge.
• Depends on PR to add NPM_AUTH_TOKEN secret (see Add NPM token to cdt-gdb-adapter .eclipsefdn#22 ).

Updates push-workflow to publish release to NPM if

• a tag is pushed to any branch. Can be further restricted to main if desired (needs a bit more logic).
• both build and test succeeded on Linux and Windows.

The publish job creates a new clone of the repo.

Intended publish process is:

• Open PR to update version number in package.json.
  • Note that this repo doesn't have CHANGELOG.MD, hence step 11 of Automate publishing of builds #379 only partly applies. Might be interesting though to add a CHANGELOG going forward.
• Draft and create a new release via GitHub web frontend.
  • The tag pushed as part of this triggers the publish process.
• Create a PR to set version number in package.json to a next version. This is not automated.

Does not include from #379

• Automated push of a new next version in package.json.
• "Atomic" operation of updating version number and pushing the tag. But I believe this is manageable for committers. You can explicitly select the commit for a release and hence the tag.

On top of this

• sneaks in a fix for building test apps on Windows with a space in the workspace path.
• cancels running workflows on subsequent push to same branch/tag.

[jonahgraham]

Wonderful. Thanks @jreineckearm

As for having a changelog in here I am ok with that. FWIW at one point I thought the best solution was to combine cdt-gdb-adapter and cdt-gdb-vscode into a single git repo, but I don't know how to do that.

As for "next" - we haven't used it in a while, so we could also just drop it to make life simpler. Which would mean a release process is running yarn version once and pushing the change + the tag.

Could make sense to make a test publish with current next version after merge.

IIUC You need to add more options to the yarn publish for this to work. Specifically you need --tag next. I think you can just publish a new version of the adapter that has no other changes. If you get added to the cdt-gdb-adapter npmjs permissions you can also run npm unpublish cdt-gdb-adapter@<version> if you accidentally publish something broken.

[jreineckearm]

As for having a changelog in here I am ok with that. FWIW at one point I thought the best solution was to combine cdt-gdb-adapter and cdt-gdb-vscode into a single git repo, but I don't know how to do that.

Let's add a CHANGELOG then during one of the next releases.
I think this would need to be done as a monorepo as we'd need to maintain separate package.json for the NPM package and the extension. Assuming we want to keep the NPM package available and not switch to an extension only.
I haven't set up one myself yet, but have some examples internally. Let's put this on the longer term roadmap. I believe the current approach of separate repos is good enough for now if we collect multiple changes for each release.

As for "next" - we haven't used it in a while, so we could also just drop it to make life simpler. Which would mean a release process is running yarn version once and pushing the change + the tag.

OK. That would spare one step.
You would only need to update the version field in package.json. The tag is specified and pushed when you create a release through the GitHub web frontend. Again like for the extension publish flow.

IIUC You need to add more options to the yarn publish for this to work. Specifically you need --tag next. I think you can just publish a new version of the adapter that has no other changes. If you get added to the cdt-gdb-adapter npmjs permissions you can also run npm unpublish cdt-gdb-adapter@<version> if you accidentally publish something broken.

I would hope it just picks the current version in package.json (v1.0.9-next). Didn't have time to register at npm today. And off tomorrow. Let me get back to this as I see the charm of being able to unpublish.

[jreineckearm]

I'll merge once the .eclipsefdn PR is merged and when I can make a test release.