User Feedback

[djredman99]

Feedback from an Enterprise Customer

Branch protection: If there are branch protection rules (in particular branches targeting * patterns) the PR creation and update part fails. Our solution in that regard was to proactively create another rule specific for the generated branch that will allow the update. there is perhaps a better approach, but I couldn't find anything that suggested that this issue was being considered.
Also, the branch to be used for the PR suggestion might need to be created under a path to guarantee the new rule takes place (ghas/ghas-something)

HTTP 403 errors misinterpretation: When reviewing if a repo has had scans in the past, if the process fails due to a permissions error of the token or app, the function was using that fail to skip the repo instead of marking a permissions error, also no logging there as to the specifics of the error (https://github.com/NickLiffen/ghas-enablement/blob/main/src/utils/checkCodeQLEnablement.ts#L28)

Issues being disabled: Given that issue tracking management is not a feature we have available at the org level (you have to go through each repo and switch if you want the tracking or not) then adding a check if issues are enabled in order to be used to communicate with repo owners could avoid surprises. In a nutshell this request https://github.com/NickLiffen/ghas-enablement/blob/main/src/utils/enableIssueCreation.ts#L14 was not enough for that scenario

As a separate idea: perhaps a config where the execution can control if they want both issues and PRs or just one of them could also reduce the confusion.

API limits: the strategies worked, and the token expiration problem also went away, wanted to thank you for that. Wanted to mention that even using the App tokens we hit both rate limits, so clearly a run for more than 1k repos is going to deplete the App API limit which is something that other organizations might face.

Flags in commands: I think that by default the commands being used should strive to reduce the number of time/resources in the clone operation, so reducing the depth and potentially disabling the LFS pull could help other engagements in complete their "enablement runs" faster.