[EPIC]: Cronmos ought to be the first repo that we use to demonstrate all of the work in oss-repo

[jtieri]

Issue Description

We should use Cronmos as the first project to host all of the new artifacts and CI setup that we have worked on in this repo. The Cronmos repo is currently missing a robust CI setup and this could serve as a good pilot repo to validate that the work we have done here translates well to an actual repo where there is collaboration happening. We can gather feedback from the team and iterate on anything if necessary.

Edit:

Preliminary Work to Finish

We will want to finish a couple of things before we go ahead and open up PRs to bring the Cronmos repo into compliance with the template repo. High level goals are getting the tutorial document finished & figuring out how to handle private repo access in CI and documenting that process

• [Docs]: There should be a document that is used as a guide when setting up new repos from the template #34
• [Docs]: Example for how to access private repo for go build, go mod tidy, etc. #44

Bringing Cronmos into compliance

After the pending preliminary work is completed we can begin work on bringing the Cronmos repo into compliance with our template. There are a few steps here that should probably be addressed in a specific order.

• Add artifacts into the Cronmos repo (e.g. adding the various documents such as SECURITY.md, CODE_OF_CONDUCT.md, CONTRIBUTING.md, etc.). If the repo is public you can use the GitHub community guidelines page to verify the repo meets the basic requirements for adhering to the OSS community guidelines and expectations.
• Configure CI/CD
• Use the linter to fix all existing linter errors/warnings. If there are a lot of errors/warnings, it may be best to break these out into a handful of smaller PRs so that they are easier to review vs. one massive PR that addresses everything. In the past my strategy for this is to fix a specific class of errors/warnings per PR, e.g. fix broken docs in one PR, fix types/grammar issues in one PR, fix areas that errors are ignored in one PR, etc.
• Use SETTINGS.md to configure all of the repo settings. One thing to note is that once the linter is configured it will probably be failing CI, so if you add the requirement that status checks for the linter must pass before PRs can be merged you may not be able to get PRs merged unless you are sure to complete the previous steps in this checklist first.
• Use the tutorial/guidelines doc to ensure that you have completed every task for brining a new repo into compliance with the template repo.
• Ensure any documents/content that should no longer exist in the repo gets deleted.
• Once you are absolutely sure that the repo is compliant with the standards/conventions in this template, add the new repo to the table in the compliant repos document. This document is used to keep track of which repos are compliant with the OSS template, who is in charge of maintaining specific repos, and any exceptions/relevant notes that are useful for managing the repos as a whole.

Code of Conduct

• I agree to follow this project's Code of Conduct