feat: manifest-bump-ci

[Anush008]

What type of PR is this? (check all applicable)

• 🍕 Feature
• 🐛 Bug Fix
• 📝 Documentation Update
• 🎨 Style
• 🧑‍💻 Code Refactor
• 🔥 Performance Improvements
• ✅ Test
• 🤖 Build
• 🔁 CI
• 📦 Chore (Release)
• ⏩ Revert

Description

This PR adds a manifest.json version bump job to .github/workflows/release.yml CI.
After the sematic-release job, the bumped release version is retrieved from package.json and automatically set in manifest.json with the author of the commit being set to the original author of the release.

Note:

https://github.com/open-sauced/browser-extensions/blob/508acea546a0843dd7c5cf4b209cc9d91606a34b/.github/workflows/release.yml#L108

Piping the author info to xargs ensures removal of any whitespace or leading characters. This is optional and can be removed.

Test runs of this updated workflow can be found here. https://github.com/Anush008/browser-extensions/actions.

Related Tickets & Documents

Resolves #53.

Mobile & Desktop Screenshots/Recordings

Not applicable.

Added tests?

• 👍 yes
• 🙅 no, because they aren't needed
• 🙋 no, because I need help

Added to documentation?

• 📜 README.md
• 📓 docs.opensauced.pizza
• 🍕 dev.to/opensauced
• 📕 storybook
• 🙅 no documentation needed

[0-vortex]

Using this technique results in needless extra commits and can be used to essentially work around anything.

Please extend the release automation or remove it entirely for a committed semantic release configuration where you don't need to use this complication 🙏

[Anush008]

I understand that this will result in an additional commit for a release, but as the issue states, version bumping of the manifest.json is unique to this particular browser extension project. Therefore, incorporating this feature into the release system would not provide any added benefits to other projects utilizing it.

Additionally, replacing this well-setup release system used across other projects with something else solely for this one project does not seem appropriate or necessary at this time.

[0-vortex]

I understand that this may result in an additional commit for a release, but as the issue states, version bumping of the manifest.json is unique to this particular browser extension project. Therefore, incorporating this feature into the release system would not provide any added benefits to other projects utilizing it.

The release action is not meant to support any other projects than open-sauced. It's a simplification so that we don't install all the semantic release packages in projects and keep the configuration centralised, an example on a better way to make npm tooling portable.

Additionally, replacing this well-setup release system used across other projects with something else solely for this one project does not seem appropriate or necessary at this time.

It is copy pasting one file, once - vs - one extra release workflow committing twice every release. It is totally the best practice to decouple the configuration if upstream does not comply with the requirements or available resources this project has available. If the way we release is different here, it should be visible in the release configuration. Making the workaround happen in another scope also requires additional documentation. Waaaaaay too much work in my opinion.

[Anush008]

That sounds right. Now when I think about it, an extra manifest bump commit for every release isn't reasonable. I'd now prefer extending the release system to do the manifest bump and keep it in a single commit. Thanks.