[FEAT] Proposed Release Mgmt Workflows

[wwsean08]

Is your feature request related to a problem? Please describe. Per conversations on discord, this is something that we want to look into, so I am using this issue to propose a solution as well as open a PR against eventually.

Describe the solution you'd like

Pull Request Workflow:

• Scan for vulnerabilities using something like snyk or another similar vulnerability scanning tool
• Consider scanning via sonar cloud (or similar) product for code smell and potential vulnerability issues using.
  • Only recommending sonar cloud because it's free for open source and something I've used before (though not extensively)
• Perform a license check to prevent unwanted/incompatible license types from being introduced into the project when new (or updated) dependencies are introduced
• Run unit tests (once they exist) to validate no regressions/issues were introduced and generate code coverage
  • I have a couple unit tests that I plan to open a PR to introduce soon.

Development Build (push to main)

• Run unit tests (once they exist) to validate no regressions/issues were introduced and generate code coverage
• Consider scanning via sonar cloud (or similar) product for code smell and potential vulnerability issues using.
  • If sonar cloud is used, for code coverage data to look right it needs to be run on the default branch so that the pull requests will show deltas.

Release Workflow: The workflow will get kicked off when a tag is created that matches a semver version (for example v0.0.1 or v1.0.0-rc1).

• Create release in github releases
  • If the tag ends in -* the release will be marked as a pre-release.
  • Change log is put in the release notes, how this is done is still TBD, ideally it would be automatic, but it could also be done via a CHANGELOG.md file, then parse out the changes and put it in the release
• The various scans outlined in the pull request workflow
• Upload a docker container to the docker registry of choice (could be useful to simplify setup depending on how things go)
• (perhaps nice to have) Automatically send a message to discord to notify users of a new TAU release with a link to it.

Nightly Workflow:

• Take care of running scrape_helix_docs.py and opening a PR automatically if there is a change
• Potentially other tasks that should or need to happen on a regular basis.

[wwsean08]

Also I realize the license checking may not be necessary, but it's something I like to do even for my open source projects, just in case.

[wwsean08]

I would also like to propose adding a "Breaking" label to this repo for PRs that introduce any breaking changes for release note generation reasons. This is unlikely to be a problem in the short term, but could be useful down the line.

[FiniteSingularity]

This all sounds fantastic. Looking at how django works, there are a few things that need to be checked, especially for any PR that introduces migrations:

1. Does the PR work for a newly-created TAU instance that uses Postgres
2. Does the PR work for an existing TAU instance that uses Postgres
3. Does the PR work for a newly-created TAU instance that uses Sqlite3
4. Does the PR work for an existing TAU instance that uses Sqlite3

[chadwithuhc]

I'd like to see version numbers displayed in the Dashboard somewhere. That way I can determine which version I am running when logged in.