Customize node version and custom build steps

[simoneb]

The action is running npm install to install pacakges in https://github.com/nearform/optic-release-automation-action/blob/main/action.yml#L51.

This raises a few questions, e.g.:

• what Node version does it run on?
• what if the project uses a different package manager?
• what if the project using this action needs to do more things in order to generate a build artifact?

Overall it sounds like more control over what's run by this action is necessary

[simoneb]

As for how to do this, a good idea might be to inspire from https://docs.cypress.io/guides/continuous-integration/github-actions#Basic-Setup.

As far as I can understand from it, differently from what we do in this action it is left to the user to check out the source code in the same step, whereas we are invoking the checkout action in the action's code.

Along the same lines, if you want a specific node version you use the setup-node action in your code, whereas the action code is doing nothing about it and it's probably using whatever version comes with the runner.

Finally, the cypress action allows to specify custom steps to run, which is also an option to include in this action

[Eomm]

what Node version does it run on?

We are running multiple node.js versions actually.

1. During the installation, we are using the runner-context version as you already mentioned.
   Using the README setup, we are using the node.js 16 from ubuntu-latest.

2. During the action execution, we are using the node.js version by the uses action:

https://github.com/nearform/optic-release-automation-action/blob/f5a2c9e944aef5510c780a0c82f61c0206dac17e/action.yml#L53

In this case, it is node.js 12:

https://github.com/actions/github-script/blob/441359b1a30438de65712c2fbca0abe4816fa667/action.yml#L30

(I'm running a playground workflow to spot these details)

Note that it seems not possible getting by input a specific node.js version:
actions/runner#1479

what if the project uses a different package manager?

Right now, the npm install we run is used to install this action because it is not built.

what if the project using this action needs to do more things in order to generate a build artifact?

I think a safer approach could be:

• let the user build the application: the dev know how to do it and the right versions
• instead of asking for a command to execute, we could ask a dist folder to clean and commit (I'm not sure this is doable for GHA security reasons)

What do you think?

[simoneb]

Right now, the npm install we run is used to install this action because it is not built.

I'm not sure about this. The action has node_modules in the repo, I don't think it does npm i for that reason.

instead of asking for a command to execute, we could ask a dist folder to clean and commit (I'm not sure this is doable for GHA security reasons)

I'm not sure I understand this. Why do we need to ask for anything if we ask the user to do whatever build steps are needed before they invoke the action? This means that in our scenario (the automerge action) the user would do:

- run: npm i
- run: npm run build
- use: this action

Then the action wouldn't need to do npm i internally anymore I guess