Github Action/Code/etc policies

[MikeNeilson]

@opendcs/opendcs-core-devs @opendcs/opendcs-triage @opendcs/opendcs-dcpmon-devs

Hello all, given that our little "OpenDCS Consortium" organization now has several repos active, it's probably time to establish some firm policies on certain topics.

The topics are:

1. How and what github actions are used (see https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#using-third-party-actions for some security information)
2. What tools are required? recommended? allowed? not allowed?
3. Should we allow/have automated release processes?
4. An actual formal process on getting large project in?
5. Code standards. Do we have one for all or allow per project?

For example (and this is personal opinion here to be clear) the way the rest_api came to us was somewhat problematic. Adam is doing a great job of getting the build and such standardized but if the was actually done more collaboratively from the beginning it's quite possible there would be less duplicated work and the work Adam is doing know could've been done from the get-go.

I suspect it would behoove us to have a process for acceptance so that something like that doesn't arbitrarily happen again... but maybe that's just me.

The idea would be to document those expectation that cover all projects within "OpenDCS the Organization" and each project can then adjust as required.

[adamkorynta]

Couple of thoughts:

1. Glad you pointed out being able to version on the hashes. Good tip.
2. TeamCity shows the JUnit test reports in a really nice UI right out of the box. I don't particularly like adding a zipped report that you have to download from the GitHub Actions page as that requires several degrees of separation to figure out why a test failed and gives no incentive to look at what tests are passing. However all of the junit report GitHub Actions seem to require special GitHub token access for forks in order to show the reports in the PR Checks. If someone has a good solution for this, I'd love to see it.
3. Really love the GitHub Codespaces (played around a bit with the rest_api) as it allows very easy onboarding for new developers.
4. Definitely in favor of having automated releases. Requiring manual deployment of artifacts is error-prone and usually ends up with only a single point-person for performing the release.
5. I think having code standard across the organization simplifies decision making. I really like the way SonarCloud/Qube handles this as Quality Profiles sets can be inherited (https://sonarcloud.io/organizations/opendcs/quality_profiles/show?name=CWMS_ATO&language=java). If there is a compelling reason for one project to change a couple of rules then they can still mostly follow all of the other standards. Additionally, SonarCloud provides detailed justifications for why rules are in place and has a nice UI for viewing and editing rules, which simplifies maintainability. Copying SpotBugs, PMD, CheckStyle, etc configs from repo-to-repo means that updating the original does not propagate to all of the projects.
6. What do we do when standards are broken? Should there be automated enforcement of the rules (PR can't merge until standards are met, for SonarCloud that's setup as a Quality Gate)? Or is that up to PR reviewers to enforce? I think regardless, the standards need to be transparent using tools that are brought in by topics 1 and 2.

[MikeNeilson]

2. Yeah. It's one of the few thing i dislike on github vs teamcity. I've been looking at how to handle custom badges and it's a similar issue of external services. Perhaps making our own simple action to push an html comment (or an xml to markdown if html doesnt work directly. Or even making use of the gh-pages or wiki repo.

Will probbaly be experimenting on that sometime this week. Got jacaco into the main project and the actual % is buried in a report.