Questions regarding the project

[jorsmatthys]

@NickLiffen

In trying to roll out this application I still have a few questions, things I noted. I wanted to hear your opinion on these first and I'll log a request if you tell me they are relevant :)

My questions:

1. The name of the project is ghas-enablement and latest version tag is currently 3.0.0, but in the package.json the project is named "github-helper" with version 1.0.0. Is there a reason for this, or is this something that could be aligned?
2. The run scripts that are foreseen to use the application first perform a build and then run the code. As far as I can tell the main reason why we couldn't just run the code is that getRepos.js writes a result to ./bin/repos.json and that the build copies this to ./lib/bin/repos.json where enable.js expects it. Having to run the build before the run slows down the execution time a bit. Is this something that could be changed/avoided ?
3. Unless I misunderstand something, the functionality of the application is somewhat limited when we use the GitHub App application. Since we refer to one specific installation (under an organization in our case), I believe we cannot really use the getOrgs.js which we can use with PAT authentication. What are your thoughts about using GitHub App application in a way that does not require you to specify a specific installation id ? (as an example: we also use github/safe-settings, where we don't specify an installation id and can target multiple organizations using GitHub App auth)
4. Could the project get a tag on the latest version (3.0.1?)

Kind regards,
Jors

[NickLiffen]

Hey @jorsmatthys 👋

Thanks so much for logging this 💯 I am very open to the conversation :) Let me try and answer your questions :)

The name of the project is ghas-enablement and latest version tag is currently 3.0.0, but in the package.json the project is named "github-helper" with version 1.0.0. Is there a reason for this, or is this something that could be aligned?

This is a very fair shout out 😢 I need to create a github action or look to see if there is one that already exists that helps automate this. There is no reason why this is behind apart from the fact it's just human error.

The run scripts that are foreseen to use the application first perform a build and then run the code. As far as I can tell the main reason why we couldn't just run the code is that getRepos.js writes a result to ./bin/repos.json and that the build copies this to ./lib/bin/repos.json where enable.js expects it. Having to run the build before the run slows down the execution time a bit. Is this something that could be changed/avoided?

Is your main question here is why we don't run it all in one command, versus writing it within two? This is a great question and something that has come up a few times, but there is a good reason why we do this. A lot of the customers who run this run it across a few hundred repositories. The value of splitting it up is there are most likely 1/2 known repositories that they don't want to run the script on. If there was no break, you wouldn't have a chance to review the contents and remove certain repositories. This was a key requirement from a few customers. So that's why we have the pause. It does double the time it is going to take, so I agree this isn't perfectly optimal. I may be open to something that would allow people to override the default and run everything together, but I would want to architect how this was going to work.

tl;dr is there a reason, to be able to remove certain repos and review, but open to adding different functionality.

Could the project get a tag on the latest version (3.0.1?)

Done 💯

--

Thanks for working with me through this repository @jorsmatthys ❤️ your collaboration makes me work on the right things. :)

Unless I misunderstand something, the functionality of the application is somewhat limited when we use the GitHub App application. Since we refer to one specific installation (under an organization in our case), I believe we cannot really use the getOrgs.js which we can use with PAT authentication. What are your thoughts about using the GitHub App application in a way that does not require you to specify a specific installation id ? (as an example: we also use github/safe-settings, where we don't specify an installation id and can target multiple organizations using GitHub App auth)

I would be very open to this and 100% correct 👍 I have been meaning to get around to this for a long time but never have 😢 I do want to do this work so please feel free to log an issue! would be very open for this 👍

[jorsmatthys]

Thanks for your feedback on all points and the new tag 👍 💯
I created an issue for the third point :)

For the second point, my main question was about running npm run build between the execution node ./lib/src/getRepos.js and node ./lib/src/enable.js. I'm fine with running both scripts separately :) I would just like to avoid rebuilding if possible, but it works perfectly, and the build time is not that long either, so this would be a bottom of the list kind of thing I suppose.