Support trusted publishing with OIDC

[anguyen-yext2]

J=WAT-5077
TEST=manual

forked the repo to my personal git account. Verified that:

• the ci-verify-publish script output the correct release tag
• the release and release:dry scripts work as expected on a new patch, minor, major, alpha, beta, and custom version

copied over the relevant changes from the forked repo. Verified that:

• the ci-verify-publish script output the correct release tag
• the release:dry script make the expected changes locally

[coveralls]

Pull Request Test Coverage Report for Build 18297306928

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 89.397%

---

Totals
Change from base Build 16660569086:	0.0%
Covered Lines:	244
Relevant Lines:	266

---

💛 - Coveralls

[Fondryext]

I think this all makes sense to me, although I'm not too familiar with the publish process.
So silly question - what's the new release flow work like? Do we just make a new release/tag in Github, and these scripts get triggered and everything works from there without our input?

I plan to approve this shortly but wanted to give any other engineers a chance to check as well

[anguyen-yext2]

I think this all makes sense to me, although I'm not too familiar with the publish process. So silly question - what's the new release flow work like? Do we just make a new release/tag in Github, and these scripts get triggered and everything works from there without our input?

I plan to approve this shortly but wanted to give any other engineers a chance to check as well

I'll confirm with Sumo later to see if they're doing the same thing, but here is how I was testing it:
Before: manually bump the version in a PR, run npm publish after merging, then manually make a release note on github.
After: make a PR without bumping the version. Once that is merged, run npm run release locally, which will prompt you to choose if you want to release a patch/minor/major/etc version, and then that script will publish the new version to npm. Similar to before, we would still need to make a release note on github page manually.

[anguyen-yext2]

I think this all makes sense to me, although I'm not too familiar with the publish process. So silly question - what's the new release flow work like? Do we just make a new release/tag in Github, and these scripts get triggered and everything works from there without our input?
I plan to approve this shortly but wanted to give any other engineers a chance to check as well

I'll confirm with Sumo later to see if they're doing the same thing, but here is how I was testing it: Before: manually bump the version in a PR, run npm publish after merging, then manually make a release note on github. After: make a PR without bumping the version. Once that is merged, run npm run release locally, which will prompt you to choose if you want to release a patch/minor/major/etc version, and then that script will publish the new version to npm. Similar to before, we would still need to make a release note on github page manually.

Just confirmed with Ben that Sumo's flow is similar

[Fondryext]

Thanks for clarifying!

[vijay267]

Let's update the Search SDK documentation to take into account the new release flow (after this / the other changes are shipped).