Release NPM versions of romcal

[emagnier]

The /scripts/ files from romcal v2 are still in the codebase, but they seem not executed anymore.

@pejulian, you worked mainly on them. Can you provide us a bit more information, how they were run... ?

FYI I only removed the auto changelog, because I think a changelog must stay for humans, containing bullet points of new things, modified things, breaking changes... (before it was just a kind-of log of the commit history).

At least, we must be able to publish new NPM package of romcal (and now, including all its calendar plugins). For the moment, we should make it manual, i.e. a maintainer (e.g. me) have to run this script manually to publish new NPM versions.

And I think it's generally better to keep it manual. So we publish new NPM versions when it's worth it (as alpha, beta, or final release).

I'll try to work on this script in the coming days.

[tukusejssirs]

I can’t comment of the scripts/ folder. However, IMHO automatic publishing of NPM packages based on the branch of each commit might help those who might want to quickly test the latest code and/or who don’t know how to build romcal from source (incl the installation of all the deps, like Node.js).

That said, for now it might be satisfactory to pubish them manually, but I think you should use this time to create a script/program in order to latter use it for automatic publishing, and also for tuning the process. Also I think that GitHub Actions have some kind of NPM publishing built-in.

[emagnier]

Thank you for your feedback, but as I already wrote in different places, this is already the goal. I just want to go step by step to ensure we set up the right tooling / CI that address effectively our need. Please be patient ;)

[pejulian]

Hi @emagnier , sorry for the late response.

The scripts/ folder was originally created to house scripts that would be executed by Travis CI. It contains code to automatically bump the version number of the module in package.json and also to automated daily branch merges from master to dev.

The whole idea was to create some sort of CD process around our code at the time. The process lacks scripts to run tests though.

Having said that, I think it would make more sense for this process (if still required) to be migrated to GItHub Actions instead; it is more integrated and less convoluted than the scripts we currently have.

[emagnier]

Hello @pejulian, thank you for your message, no worry for the delay 😄

Yes so now it makes sense, I've removed the .travis.yml config file at the beginning of my work on romcal v3, but didn't pay attention that it also contains the instruction to run most of these scripts.

On romcal v3 the idea is indeed to migrate them to GitHub Action. There is already one first "Action" that run tests and build, every time a commit is added to the repo. The next goal is to script the NPM publishing of romcal and all its new calendar plugins, similarly has you made it with the Travis CI scripts.

[tukusejssirs]

@emagnier, I think this issue is fixed by #332, am I right? Or is there something left to do?

[emagnier]

Yes, we still need a GitHub Action to manage Romcal releases from the master/prod branch, and release final npm versions of Romcal.