I wanted at least once a month, so if your workflow log retention is 90 days, we could at least see more than one past run.

Only config.guess and config.sub need to be updated if changed upstreams. No need to, in fact shouldn't, run autoconf.

Only config.guess and config.sub need to be updated if changed upstreams.

When does this file get updated then?

No need to, in fact shouldn't, run autoconf.

It's a starting point. I copied the old doc from https://github.com/OSGeo/grass/blob/releasebranch_7_8/doc/howto_release.md#update-of-configure-base-files

Now we can tune what we want exactly, since it's easy to see what is done.

Only config.guess and config.sub need to be updated if changed upstreams.

When does this file get updated then?

configure runs the two files as part of configuration. The configure itself only needs to be updated (generated) when changes are applied (namely to configure.ac or aclocal.m4).

No need to, in fact shouldn't, run autoconf.

It's a starting point. I copied the old doc from https://github.com/OSGeo/grass/blob/releasebranch_7_8/doc/howto_release.md#update-of-configure-base-files

Now we can tune what we want exactly, since it's easy to see what is done.

This is a great enhancement! And skipping the autoconf part, it will be even more simple.

configure runs the two files as part of configuration. The configure itself only needs to be updated (generated) when changes are applied (namely to configure.ac or aclocal.m4).

If you run ./configure three times in a row without changing the source code, will ./configure have the same output?
If so, if there are changes to make to the configure script, should this workflow be the safeguard that it stays updated?

I realise that it shouldn't be ./configure that updates ./configure, but by question is more like, could we run the tool(s)/script(s) that update the ./configure file to make sure it is kept updated and in sync with the files committed. The PR generated would trigger the full CI to check that it works, if the CI can assure us to that :)

If you run with an unpatched version of autoconf 2.69 (which you should), then there will be no changes. Several distributions do have patched versions.

I realise that it shouldn't be ./configure that updates ./configure, but by question is more like, could we run the tool(s)/script(s) that update the ./configure file to make sure it is kept updated and in sync with the files committed. The PR generated would trigger the full CI to check that it works, if the CI can assure us to that :)

If you could manage to build a "clean" autoconf version 2.69 on CI, run autoconf with that version and if configure did change, then the workflow could create an Issue (not PR). The reason for this is, eventual changes in configure.ac/aclocal.m4 might/should have introduced changes in /include/grass/config.h.in updated by autoheader. That file (config.h.in) is since the dawn of time manually modified in GRASS source and for the time being must be also updated with oversight. (In fact this kind of check would be good for every PR which modifies one of configure.ac or aclocal.m4.) This could perhaps be better be addressed in a follow-up PR.

However I support the very simple and uncontroversial approach to create a PR with updated config.guess and config.sub.

Besides the minor (cleaning up) issues noted in the comments above, this looks fine to me!

I saw the comments yesterday.

I also have in my fork some playing around with the clang-format. It makes no sense that it takes 22 min+. The action used calls a docker container mapped to a single file, for every file in the entrypoint.sh. I used an action that logs the cpu/memory usage throughout a workflow run to visualize that it was really one thread, and mostly system cpu time. I quickly tested out using another clang-format action, to be sure to see what gains we could have before trying to file some details at the action, and it was roughly 27 seconds out of 47seconds. I was waiting for some input on my previous PRs to continue working on it.

I think it is at what you wanted. Since it doesn't check that it builds, if ever the run doesn't fail, I added a note in the PR's message to go check the logs if the two files were deleted and not replaced.

I think it is at what you wanted. Since it doesn't check that it builds, if ever the run doesn't fail, I added a note in the PR's message to go check the logs if the two files were deleted and not replaced.

This seems to work fine and it is all this need to do. Thank you!

Just please run the file through pre-commit and correct the warnings/errors.
(We really need to introduce pre-commit.ci, but that is another issue...).

I never used pre-commit before, but I tried something. The remaining yamllint warning is with the comment with the action ref, I don't know how to fix it, since for renovate to pick it up it should be on the same line?

I saw one of your PRs that added an extra space, I think that does it!

Ready to merge?

Ready to merge?

From my point of view, yes. Waiting for approval from @wenzeslaus as he previously had some issues.

There's been no objection for a week!