ci: Add workflow to regenerate static assets

[PythonGermany]

Summary

Closes #1454. This workflow will never work if the pull request author has set the PR option Allow edits and access to secrets by maintainers to false.

I am currently not sure how to easily test if the permissions are given to push to the feature branch of the PR in the forked repo when the workflow runs in the base repo.

If there are no checkout or push permission issues the workflow works. I already tested it with PRs in my fork with the base in the same repository.

TODO

• Make sure only trusted sources can trigger workflow, e.g. a specific actor or only people with write access! -> covered by github/command action

Checklist

• (n/a) Tested and/or added tests to validate that the changes work as intended, if applicable.
• (n/a) Updated documentation in README.md, if applicable.

[PythonGermany]

@TwiN We can start thinking about how to test/introduce this properly. Does the current version already cover all the needs for this repo? I don't want to make it more complicated than it needs to be.

The issue with testing is that the workflow trigger issue_comment only works once the workflow is in the default branch. I don't know how to test if everything works in terms of permissions, since I'd probably first need to create a second GitHub user to fork a test repo containing the new workflow to test the whole final scenario before actually merging it. Can you think of an easier way?

[TwiN]

There's no need to test this. I'll manually test it once it's merged in the master branch, and make adjustments as necessary.

[PythonGermany]

There are still two open questions I have:

• Whether or not to allow the workflow to be run on draft pull requests
• Whether or not to require reviews before this workflow can be run

The restriction to require reviews required probably makes sense and if reviews are required the restriction to only allow non-draft PRs makes sense too since draft PRs can not be approved, I think.

[TwiN]

Yes for the former, no for the latter.

Does this currently not work for draft PRs?

[PythonGermany]

Does this currently not work for draft PRs?

The default for the action is not to allow it. I enabled it now.

Have I understood correctly: The wanted behavior is like this?

allow_drafts: true
skip_ci: true # Meaning CI check do not need to pass to allow updating static assets
skip_reviews: false # Meaning there needs to be a review before updating static assets is allowed

If any conditions fail the action will add a comment to the PR explaining which condition is not met, e.g PythonGermany#23 (comment)

[PythonGermany]

Just tested it again, in my fork it works just as intended: PythonGermany#18 (comment)

[TwiN]

Excellent work, @PythonGermany!

[TwiN]

@PythonGermany To answer your questions, it seems to be perfectly configured as-is in your branch

[PythonGermany]

Great to hear. If there are any issues let me know!

[TwiN]

It's perfect! The only thing I'd change about it is perhaps add a comment to the PR if no changes are detected, and if possible, also add the workflow status to the PR as it seems to just be running with no status indication, but honestly that's nitpicking. As-is, I find the feature very useful. Thank you again for taking the time to add it :)

[PythonGermany]

add a comment to the PR if no changes are detected

That's a simple change: I opened a PR for this and other adjustments #1480 🎉

My initial idea/approach was to only post comments if absolutely necessary and work with reactions on the initial triggering comment instead -> Advantage: no notification spam; Disadvantage: No notifications and not very intuitive since the reactions are quite limited on GitHub. The only scenario where it somewhat works is for the success scenario when a commit is created after a while.

also add the workflow status to the PR as it seems to just be running with no status indication

I'm not sure if I understand exactly what you mean. Do you mean adding (maybe prepending?) the status of the workflow to the PR title? If that is what you mean I would suggest using labels instead, because the title approach is not scalable to multiple workflows that want to indicate a custom status.

The only status indications for the workflow currently are the comment reactions. E.g the 👀 reaction indicating the workflow has started, which seems to be the "standard" for workflows triggered by a user comment, actualbudget for example has a ton of workflows that do it this way.

Maybe I just don't get what you mean and you are referring to another type of status indication?

Another idea I have would be to create a comment informing that the workflow has started with a link to the workflow status site and then update the comment with the corresponding status once the workflow has completed.

[TwiN]

No, no, I'm referring to adding the regenerate assets workflow that runs to the PR's list of actions when it runs, if it's possible. So like if I wrote the comment that triggers the workflow, it would show up in the list of statuses on the PR

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/about-status-checks

Those status checks: