Investigate using automated GitHub Actions

[ian-jarrett]

Investigate what capabilities are possible with GitHub Actions, when a release is built.

Suggest forking a repo and experimenting on that. Is it possible to check syntax (linting), dependencies, vulnerabilities etc. when a release is built?

Will require test automation

[ian-jarrett]

I can think of 2 possible workflows where GH Actions might be useful:

• First, development: what I usually do is fork a repo first (such as https://github.com/Juniper/nita), which creates a local version for me personally. Then I'll clone it to my dev environment (such as a VM on my laptop, or in JCL). In my dev environment I'll do my work, making changes etc., and use "git add" and "git commit" locally. When I'm done there, I'll do a "git push" back to my personal github repo. There might be GH Actions that are helpful at this stage, when a "push" is done, but likely the benefit will only be "personal". Once development is compete, from my personal GH repo I'll sync it with the parent by creating a pull request. This is another time where GH Actions might be useful, perhaps running in the parent repo. (BTW, branching isn't necessary).

• Secondly, when we build a release. After all of the changes are pulled in, we'll cut a new release. We currently do the following tasks by hand:

• Create a new version number (e.g. 24.5), usually based on date, and add it to a VERSION.txt file

• Update the "NOTICES" with any dependencies <- this is a pain, if we can automate it, it would be great

• Add a "LICENSE" file if one doesn't exist

• Update the version and copyright date in the README <- also a pain

• Create a tag based on the version number (e.g. 24.5-1) and tag files in the "main" branch with it

• Create a release with the same tag number and mark "main" as being the latest release

• Create a branch with the new version number (24.5) which is basically a snapshot of everything in main

• Post a message onto Teams to say it is done

• Ashley also creates new docker images and pushes them to docker hub... please ask him how he does this, but it should be possible to automate that too.

Hopefully that's plenty of ideas to investigate... if you can help reduce some of the manual tasks for building a release, that would be a win. You'll also note that we don't do any "extras" yet, like linting (checking syntax), checking for security vulnerabilities or running automated tests. They would all be extra wins if they could be automated too.