feat: use manifest-beta for BRAT pre-releases

[johannrichard]

Thanks for a great plugin! I implemented a small change that will create a manifest-beta.json in case a pre-release is detected (e.g. when committing to a beta or next branch). This will then create a manifest-beta.json for that pre-release and commit it to the branch, but will leave the manifest.json untouched.

Because of the way BRAT (currently) works, you either have to set your pre-release branch as the default branch and update it's manifest.json manually whenever a new version is published, or copy the manifest-beta.json from your pre-release branch to the default branch.

I'm not sure which one is the best way, or if there are better ways to solve this (including updating BRAT such that a branch could be specified instead of manifest-beta.json or a fixed version number).

[johannrichard]

I submitted TfTHacker/obsidian42-brat#93 to obsidian42-brat. In case it is integrated, the code required to create, update and commit the manifest-beta.json would not be needed anymore, and the problem outlined above would vanish. Happy to keep that PR open as aa draft as long as this question is not solved.

[brianrodri]

This looks great, thanks for the contribution! I'd be happy to merge this in but please add a TODO(TfTHacker/obsidian42-brat#93) comment somewhere so that I can remember to remove it once and if your PR goes through.

I'm not a big user of BRAT, so let me know what'd improve your experience the most. Thanks again and happy new years! 🎉

[brianrodri]

Heads up I merged in some changes to your branch so that it's passing my checks!

[johannrichard]

@brianrodri I have continued playing around with the plugin. It's really great! I have written up a small Gist with a sample .releaserc.yaml which contains a boilerplate configuration that should work with minimal adjustments for almost every Obsidian plugin. This works without polluting the package.json (which is especially useful when tinkering with (development) forks, for which one can now release test versions with a breeze).

I also wrote up a small README.md on Using semantic-release for your Obsidian plugin and development forks alike that briefly explains how to use your plugin in different contexts.

[brianrodri]

Got it, thanks @johannrichard! I've gone ahead and given the code changes a genuine review, PTAL!

I'll also play around with the .yml snippet on a private repository to quickly confirm, then I'll open a PR myself with the changes. Would you mind reviewing those changes when I get around to it?

Finally, thanks again!!

[brianrodri]

This seems a little complicated, could you please split these into a chain of if-else with brief comments describing how a user might "land" in each branch?

Also, please add some unit tests to demonstrate the same ideas (and so codecov stays at 100% 😊)

[johannrichard]

PS: I saw there's a longer thread in the Obsidian Forum on GitHub actions. None of them mention your semantic-release plugin, and all of them involve quite complex setups with additional scripts. I was thinking a) of replying by adding a pointer to your plugin (b/c it's really great and works well out of the box 🥳) and b) of shamelessly adding a link to my small write-up (relevant parts of which we can also integrate into your plugin's doc if you prefer).

Please let me know what you think of a) and b).

[brianrodri]

Haha b) sounds good to me!

They'll need a link to this repo to file feature requests anyway 😎