Settings notags

[DavidGOrtega]

This PR adds:

• settings.js to setup the different settings across the project. closes Settings file #23
• remove tags by default. closes No tags by default #14

[shcheklein]

are those env variables?

[DavidGOrtega]

yes, thats the way they are set. In Github actions you can set env variables or inputs that are indeed env variables that they manage prefixing with ENV_ that you access with core.getInput

[shcheklein]

is it the same convention to set them in lower case for Github and Gitlab? In both systems they become env variables?

Should we actually make a title that clarifies the purpose - configuring the action? Probably users don't care how these setting are being passed to the code

[DavidGOrtega]

is it the same convention to set them in lower case for Github and Gitlab?

Yes you can use upper or lowercase. In gitlab is called variables and is the same ENV variables in the executor. If you see both yml are mostly the same aside the naming differences. That was done on purpose. Thats why we removed the inputs in Github in favour env variables. In fact there are some variables in gitlab that has to be set in the UI like secrets in Github, again all that env variables and its up to you if use lowercase or not.

Should we actually make a title that clarifies the purpose - configuring the action?

Maybe, for gh is more clear since the cant go wrong using inputs, in the case of gl I guess there is no way of mess, there is only one type of variables

[shcheklein]

Maybe, for gh is more clear since the cant go wrong using inputs, in the case of gl I guess there is no way of mess, there is only one type of variables

don't quite understand the point

[shcheklein]

so, if we go with env vars, why don't we use upper case?

[shcheklein]

also, still think it's better to name titles from their actual purpose - the problem they solve (not from the implementation details of the solution for the problem)

[DavidGOrtega]

I have updated the docs a bit in this commit. Have you seen it, does it conforms a bit better your needs?

[shcheklein]

why do we need to export this?

[DavidGOrtega]

They are used across the other modules. If they are not exported they are not visible.

[shcheklein]

but we have them in settings now, right?

[DavidGOrtega]

Yep, but they will be like private for the rest of modules. Have to be exported.

[shcheklein]

why private? no sure I understood the logic to be honest

[DavidGOrtega]

everything inside a module in js not exported in not visible from outside

[dmpetrov]

looks good

[DavidGOrtega]

@shcheklein It's ok to merge?

[shcheklein]

@DavidGOrtega yep!