Devops/build updates

[MikeNeilson]

More detailed build status reporting in preparation for proper trunk based development -- e.g. it's at least really obvious required builds are passing to justify releasing to test or prod.

Might be some other bits to fix as well, secret wise at CWBI, but some of that can be handled within the github secrets once the repo is allowed to push to all the appropriate environments.

FYI the short term goal is that, some approved group, can just tag a commit appropriate (creating a realize or using git tag locally) and automate the push to the environment. (Only dev would remain scheduled. Though if this all works better I think test is justified for that treatment, perhaps just on a different schedule.)

[adamkorynta]

To clarify the badges logic - is the intention to generate badges on every PR or just the main branch? It looks like it is running a job to create a badge and push that badge to a special "badges" branch, but from first glance, it doesn't look like that'll work from forks.

If we only need it on main (and probably release branch for now), could we instead leverage github pages and just upload the SVGs there and then just reference from the README.md?

[krowvin]

Suggested change

	if [[ "${NIGHTLY}" == true]]; then
	if [[ "${NIGHTLY}" == true ]]; then

[krowvin]

I think there are some version references still? This might be empty now

[krowvin]

{REPO} as well

[MikeNeilson]

Those are now set in the env: block you see starting on line 151.

[krowvin]

Where is $REPO coming from I see it removed in other places

[krowvin]

Do not use a p tag to wrap tables or h2 tags

It might still work

https://stackoverflow.com/a/10087069

Edit: div should work!

[MikeNeilson]

To clarify the badges logic - is the intention to generate badges on every PR or just the main branch? It looks like it is running a job to create a badge and push that badge to a special "badges" branch, but from first glance, it doesn't look like that'll work from forks.

Thank you, just the main, I just needed to run on the local branch for testing with nektos/act

At least the publish step anyways, I'm going to keep the badge generation as that's a build artifact with a short lifetime.

If we only need it on main (and probably release branch for now), could we instead leverage github pages and just upload the SVGs there and then just reference from the README.md?

That's basically what I'm doing, just with a dedicated branch for badges, we may include other build statistics over time to be able to report more detailed findings. Plus I didn't want to risk interfering with gh-pages as then there might be updates from multiple things.

[adamkorynta]

GitHub Pages allows for publishing and overriding only specific directories so it wouldn't conflict with any other operations (unless of course they were setup for some reason to blow everything away). I'm a little concerned with growing complexity of the actions. Having a dedicated commit for the badges doesn't give us any more information than the build status history from the Actions tabs either.

[MikeNeilson]

GitHub Pages allows for publishing and overriding only specific directories so it wouldn't conflict with any other operations (unless of course they were setup for some reason to blow everything away). I'm a little concerned with growing complexity of the actions. Having a dedicated commit for the badges doesn't give us any more information than the build status history from the Actions tabs either.

I'm all for magic that simplifies the actions, but I don't see it happening. We need to build and test against multiple databases, verify several elements can be created correctly, and be able to automate actual deployments to environments. For USACE's usage of OpenDCS we do have the deploy elements in a separate repository from OpenDCS itself, it most certainly doesn't reduce complexity.

As for the badges giving more, perhaps not, but we can't pull the individual matrix status out of the build status in a simple way so I'm creating a badge per matrix build so they can be seen individually. I will also expand to other metrics, that at least for this repo, are not as easily provided by other external tools, such as coverage.

But I may also just be misunder standing something here. I'm thinking of the gh-pages as a branch... is there also just a target to be overridden that isn't a git respository I'm not thinking about correctly?

[adamkorynta]

I was looking at this action: https://github.com/peaceiris/actions-gh-pages which has the ability to keep_files and destination_dir which would allow this action not to clash with any other github pages content we may automate in the future.

[MikeNeilson]

I was looking at this action: https://github.com/peaceiris/actions-gh-pages which has the ability to keep_files and destination_dir which would allow this action not to clash with any other github pages content we may automate in the future.

So looking at that action, the only difference is that it's using the gh-pages branch by default, it even has the option to use a different named branch (so does github pages).

Given this is pushing something into our repo either way, and a simple git add/commit/push isn't difficult, I'm inclined to write this out and not have yet-another-dependency that would need and have access to the GITHUB_TOKEN value... and yes, I am in fact paranoid.

[krowvin]

I expect the two failed tests are unrelated?

[MikeNeilson]

I expect the two failed tests are unrelated?

Yeah, change to the database latest got merged in and the issue is now exposed here. Failures on the latest schema build are generally expected as they have different life cycles; that particular build is thus a canary and not a show stopper.