Ideas for possible enhancements

[djthornton1212]

So, I've been troubleshooting the app for a few days now and noticed a few things that might make it a bit more efficient.

1. Can the local branch be created prior to creating the remote?

   • Reasoning: If the local command process fails, we now have an orphaned remote branch. During my troubleshooting I think I've deleted about 50 of them.

2. Can a cleanup process be introduced in the event of a failure?

   • Reasoning: I've found that if you have to re-run the yarn run start command after a failure in the commands process you must manually delete the tempGitLocations folder, else the process will fail with:

   Error: Command failed: cmd /s /c mkdir tempGitLocations
   A subdirectory or file tempGitLocations already exists.

   • An example of how this might work would be if there's a failure say anywhere after const ref = await createBranch(defaultBranchSHA, owner, repo, client); in the workers.ts file make a best effort attempt to remove the local/remote branch created.

3. Remove the -p argument from the mkdir commands in the Windows section of the comannds.ts.

   • Reasoning: This isn't a windows command argument for mkdir, unlike linux/mac. What happens is Windows interprets this as another folder to be created. This is why the rm -rf ./-p/ commands exists... to clean those up. It serves no purpose.

4. Allow for multiple languages to execute simultaneously.

   • Reasoning: It breaks the flow and requires running the app multiple times. If the app could accept multiple languages in one run that would then only require running the application once.
   • ex: .env -> LANGUAGE_TO_CHECK=java,javascript,python => Allow the application to apply the correct codeql-analysis-.yml files based on the repository's language. By the apps current design this isn't possible because the language isn't stored anywhere accept the .env file. If someone (for some reason) changes the language after running getRepos... that would be an issue. Instead maybe getRepos could store the language in the repos.json file along with its repository. Then it could be read from there when the time comes to write the codeql...yml file.

[jorsmatthys]

I had the same thought described in your point one :) I also got many branches on the remote while I was testing/failing initially.
Would also love to see your point 1,2 and 3 implemented and I think they would not be too much effort either (assuming you can easily define some code that has to be run regardless of failure/success).

I suspect point 4 might be bit more effort 😃

[djthornton1212]

Hey @jorsmatthys, I suspect you're correct about the amount of work this would require. I've a mind to keep working on them in my fork. If only to learn more about javascript/typescript as my experience is virtually 0 lol.

I was able to handle step 3 in my fork. It determines what OS type we're using and uses the right command per OS.

[jorsmatthys]

When it comes to keeping things clean, I think it might also be nice to not only check for the presence of a codeql-analysis.yml file but also check for existing pull requests for ghas-* branches (or perhaps for pull requests with identical contents). We plan to run this on a schedule and even if we run it fairly infrequently I think we will run into projects where the pr had not been closed yet.

Edit: actually I suppose content checking would not be required and it could always close the previous pr created by ghas-enablement since we want the latest version of our template codeql-analysis.yml

[djthornton1212]

@jorsmatthys I had the same thought. It turns out in my organization 100+ repos some had already deployed codeql-analysis.yml and this just attempted to modify their existing implementation of it. At least for consistency purposes it was fine. But, if I want to run this again and they still have an open PR, yeah that might get confusing. I like the idea of it closing the existing PR in favor of this or updating the existing PR.

Maybe once it does the clone it can look for a branch with ghas-*, check it out, find the existing codeql-analysis.yml and update it, commit, push. That's probably more work than was intended for this project though... but, if they're open to it...

For us though this is an initial step as we're adding codeql into our CI workflows, so the standalone will eventually get replaced by it.