Add GitHub workflow to run autoreconf and regen configure on demand

[CAM-Gerlach]

There was a desire among the core devs to allow easily regenerating the configure script using autoreconf, to avoid having to pull and run a docker image locally, or install and run the correct version of autoreconf manually, as well as avoid any unnecessary churn due to being regenerated in different environments.

We should be able to just use our own GitHub Action, which is basically the pre-commit lite approach minus installing the pre-commit GitHub Application and giving it access rights. We use this approach on the Docrepr project to automate generating consistent updated reference screenshots for visual regression tests and commiting them to a PR, triggered on-demand via a comment. (It's actually somewhat more complex than we'd need, since it has to run on multiple platforms to generate the screenshots for each)

Right now its triggered by a comment, but it would be relatively straightforward to change that to a label or manual dispatch. The other option is to have it run automatically as a precursor to the Build workflow jobs and update the PR's generated configure if its out of date, but that could get a little complicated to set up, be potentially surprising/confusing to contributors, could suffer from race conditions and not really save that much time over an explicit comment, so I suggest we start with an explicit comment trigger (or a label, etc.).

Might also be a good idea to drop-in gh for hub, since its newer and might simplify things a touch (it just might need a couple other tweaks for that, so I didn't do it yet).

Other than that, once the configure.ac is updated to work with Autoconf 2.71 (since that's the version currently used on the ubuntu-22.04 runner, and the standard version these days), we should be able to just drop in the below workflow in to have autoreconf be run in the GitHub Actions CI for a specific PR and commit the results back to the PR automatically. (I can test it on my fork to make sure it works—though as I'm a complete autotools n00b, I'll need help if I run into any autoconf specific problems).

name: Regen Configure

on:
  issue_comment:
    types: [created, edited]

permissions:
  pull-requests: write

jobs:
  regen-configure:
    if: ${{ github.event.issue.pull_request && contains(github.event.comment.body, 'Please regenerate configure') }}
    runs-on: ubuntu-22.04
    steps:
      - name: Checkout repository
        uses: actions/checkout@v3
      - name: Configure hub setting to use HTTPS
        run: git config --global hub.protocol https
      - name: Checkout the branch from the PR that triggered the job
        run: hub pr checkout ${{ github.event.issue.number }}
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      - name: Regenerate configure
        id: regen
        run: |
          autoreconf -ivf -Werror
          echo "changes=$(git diff-index --quiet HEAD -- && echo 1)" >> $env:GITHUB_OUTPUT
      - name: Commit regenerated configure
        if: steps.regen.outputs.changes == '1'
        run: |
          git config user.name 'github-actions[bot]'
          git config user.email 'github-actions[bot]@users.noreply.github.com'
          git pull
          git add -u
          git commit -m "Regenerate configure"
          git push
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

[arhadthedev]

This new action could do the generation not only on demand, but also for Check if generated files are up to date being its dependency and feeding the generated file through https://github.com/actions/cache.

[arhadthedev]

Probably, we have no need in the action altogether; the Check if generated files are up to date already prints a diff with the fix:

cpython/.github/workflows/build.yml

Lines 117 to 125 in 278030a

	if test -n "$changes"; then
	echo "Generated files not up to date."
	echo "Perhaps you forgot to run make regen-all or build.bat --regen. ;)"
	echo "configure files must be regenerated with a specific version of autoconf."
	echo "$changes"
	echo ""
	git diff --staged || true
	exit 1
	fi

[CAM-Gerlach]

This new action could do the generation not only on demand, but also for Check if generated files are up to date being its dependency and feeding the generated file through https://github.com/actions/cache.

Yeah, great idea—that would take advantage of our existing workflow and remove the duplication between them. Basically, we could move the check_generated_files job back to a separate workflow triggered both on push/pr or on a comment and with write permissions, save the changes as a patch which could be cached per-commit), only run the generate steps if the cached path is not present, and add a push changes to PR step based on the above that only runs if the trigger is the magic comment. That way, the commit changes back to PR command should run nearly instantly, as all it needs to do is commit the already-generated patch to the PR branch.

For user convenience, we could also have the part you highlight prominently print the trigger phase to automatically commit the generated changes, as well as upload the patch as an artifact in case people want it that way.

I'm not sure if you're suggesting to actually commit the changes automatically without an explicit user request; given it is relatively infrequent and should only save a few seconds, and there are a number of potential problems with that approach I'm not sure its a good idea at least initially, and think we should stick with an explicit command for now, like with other similar bot actions.

Summary of issues

• Will automatically commit to the contributor's branch without any warning
• Will invalidate and trigger another parallel run of the CI jobs
• Risks triggering a race condition if multiple CI runs are in flight at once, or if the user commits another fix before the CIs finish
• It might not be desired in some cases, e.g. if the output is not what is intended, if the modification was accidental, the user wants to wait to regen once after a series of config changes/testing, or wants to do it themselves, etc.
• If it hits some kind of bug or output instability, it could theoretically get stuck in a loop committing repeated changes, which each kicks off a new run

Thanks!