ci: simplify release workflow configuration

[derberg]

Description

• using --if-present with all npm scripts. Before release configuration was a problem as you could easily forget to add some script that was just echoing message that script is not yet implemented. Now release configuration per repo will be simpler, you add scripts only if you really need them
• remove the need to have all these different dev dependencies in package json
  • this was generating lots of conflicts with libraries using the same packages as peer dependency. Also keeping track on versions of plugins and their match with semantic-release
  • now we are installing dependencies inside release workflow, and only specific versions that we know always work.
  • as you can see we basically now install just one plugin and only semantic-release. It is because semantic release is now shipped with many default plugins included
  • this change that will go to all nodejs repos has been tested here fix: remove deps related to release and switch to npx and non-node config generator#815
• remove boilerplate release configuration from package.json. Until now every maintainer had to add it manually. Now we keep config in .releaserc and can push it out as global file to any repo that needs it.

---

Breaking Changes

tl;dr After we merge this PR, changes in if-nodejs-release.yml, if-nodejs-version-bump.yml, bump.yml files no longer will be replicated to all nodejs projects

it doesn't mean they will stop working, it's just that future improvements will not be pushed there

Why?

semantic-release uses https://github.com/davidtheclark/cosmiconfig for loading configurations, and according to their docs, unfortunately, first priority is package.json and later dedicated files 😞 In theory it should not be a problem, but because of different dependencies on package.json level and the ones installed in the workflow...I just do not want to "assume all will be fine"

Also, the cleanup anyway has to be done in the repo before new workflows are applied.

What will maintainers have to do?

There will be instructions, but basically they:

• need to cleanup package.json from dependencies, and release config
• add proper topics to reposiotory
• once merged, they need to ask .github repo maintainers to run workflow that will push new workflows to the repo

---

what do you think?

Related issue(s)
Resolves #172

[derberg]

I was thinking that we can introduce such pattern for topics for future, so they start with get-global prefix

what do you think? better ideas

example: 👇🏼

[derberg]

@KhudaDad414 can you have a look? these topics names 🤔

@jonaslagoni @magicmatatjahu @smoya pinging you so you are aware of this proposal. That with merge of this PR, auto updates of release and other workflows will stop until repo owner opts in again. Advantage in your cases is modelina next releases and parser/parser plugin releases. So you can easily modify bump workflows there as you need for your cases. Then once you are done, you can opt in again. Aaaaaaand long term this will be a feature, that on specific occasion you can just opt-out from release workflows updates whenever you want by just removing the topic. Does it make sense?

[KhudaDad414]

LGTM! just a teeny-tiny question. HOW DO YOU TEST THESE CHANGES? 😆 Definitly interested to know what is your approach in working with CI/CD. maybe an article 🥺 👉👈

[derberg]

@KhudaDad414 dude you expect too much from me. I asked ChatGPT for you but even AI provides stupid answer 🤣

On the serious side. I know https://github.com/nektos/act is there and is very popular, but I was too lazy to try it out 😄

I have 2 approaches, also because in complex scenarios I do not trust tools to do proper integration tests for me, and I value manual testing more (this is why there are still 100s of companies still having big teams of manual testers)

• I have separate test GH account where I manually test big stuff, and main repo is https://github.com/lukasz-lab/.github. I use it in majority of cases for testing the global workflow features. And I also have a repo on my main profile where I ran tests https://github.com/derberg/test-experiment/
• And what I do additionally now. If change can do some damage and I'm not sure of it. I first add it to one repo. In other words changes that I introduce in this workflow, were tested in production in fix: remove deps related to release and switch to npx and non-node config generator#815 first

Sorry for disappointing you 😄

[KhudaDad414]

@derberg thanks mate for the explanation.
I actually tried act but since our workflows are not that simple it let me down. 😆

[derberg]

/rtm