Update CI to detect uncommitted changes

[dbkegley]

Our CI workflows currently attempt to generate docs and commit the result directly to the PR branch. This workflow prevents subsequent CI checks from running because GHA cannot trigger itself in PRs.

This change updates our workflows to force developers to generate docs locally and commit the result, avoiding the annoying necessity to create an --alow-empty "trigger ci" commit.

CI will now fail if uncommitted docs changes are detected. These changes are usually either an updated Chart.lock or README.md. They can be updated with just update-lock and just docs respectively.

Example docs failure:

[dotNomad]

This change updates our workflows to force developers to generate docs locally and commit the result, avoiding the annoying necessity to create an --alow-empty "trigger ci" commit.

If the option is generate something locally and commit, versus trigger CI with an empty commit I think I would prefer the later during the release process. It is quite nice to not rely on anything being setup locally.

[lucasrod16]

This change updates our workflows to force developers to generate docs locally and commit the result, avoiding the annoying necessity to create an --alow-empty "trigger ci" commit.

If the option is generate something locally and commit, versus trigger CI with an empty commit I think I would prefer the later during the release process. It is quite nice to not rely on anything being setup locally.

I agree with @dotNomad. I'm curious if there's a way to configure the docs commit in a way that actually allows CI to run

[dbkegley]

This change updates our workflows to force developers to generate docs locally and commit the result, avoiding the annoying necessity to create an --alow-empty "trigger ci" commit.

If the option is generate something locally and commit, versus trigger CI with an empty commit I think I would prefer the later during the release process. It is quite nice to not rely on anything being setup locally.

IMO this makes the product releases easier to automate because it won't require developers to go push an empty commit to unblock CI during the release. There would be no need to run anything locally because we can automate just docs during our release process.

For outside contributors we currently don't allow CI to run at all (#62) which is preventing community engagement. It has also proven challenging in the past for contributors to know how to make simple changes because CI gets stuck and it's not obvious how to unstick it.

#505

[lucasrod16]

It would be helpful to log what the uncommitted changes were

[lucasrod16]

IMO this makes the product releases easier to automate because it won't require developers to go push an empty commit to unblock CI during the release. There would be no need to run anything locally because we can automate just docs during our release process.

Oh I see. I didn't realize that was the intended workflow. That makes sense to me

[bschwedler]

I like this approach. This moves the responsibility of updating the docs to the PR creation process.