Skip to content

Conversation

@desrosj
Copy link
Member

@desrosj desrosj commented Feb 5, 2025

This adds a workflow that automatically commits missing changes to versioned files managed through the build process when they are missed.

This was created primarily to help ensure necessary changes from Dependabot PRs are included so that various workflows pass, but it also helps contributors make sure they are not forgetting something.

The use of a GitHub App is required because of how permissions are limited for Dependabot PRs. Pushing to a branch created by Dependabot (or another fork) without the use of an app results in no GitHub Actions being triggered and defeats the purpose.

I have been testing this on my fork where Dependabot is currently configured to monitor all direct npm dependencies. View any Dependabot PR to see this workflow committing back changes to built files: https://github.com/desrosj/wordpress-develop/pulls

Trac ticket: https://core.trac.wordpress.org/ticket/62221


This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

@johnbillion
Copy link
Member

Am I right in thinking that when this gets merged, it'll need to have an additional github.repository == 'WordPress/wordpress-develop' condition so that the workflow doesn't attempt to run on PRs from forks (and fail due to missing secrets)?

@desrosj
Copy link
Member Author

desrosj commented Feb 12, 2025

Am I right in thinking that when this gets merged, it'll need to have an additional github.repository == 'WordPress/wordpress-develop' condition so that the workflow doesn't attempt to run on PRs from forks (and fail due to missing secrets)?

Ah, yes! That's correct. I forgot to make that change in this PR since I copy/pasted from my fork where I needed this to run for testing purposes.

Copy link
Member

@joemcgill joemcgill left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this idea. Using it to ensure changes to built files are added to PRs helps speed up the committer workflow as well. I could see us extend this to all PRs and not just the automated ones eventually.

Optionally, could we use this same workflow to cause a PR from a fork to fail a commit check if there are uncommitted changes so the contributor (and code reviewer) sees that feedback?

Comment on lines 171 to 180
- name: Stage changes
if: ${{ steps.built-file-check.outputs.uncommitted_changes != '' }}
run: git add .

- name: Commit changes
if: ${{ steps.built-file-check.outputs.uncommitted_changes != '' }}
run: |
git commit -m "Automation: Updating built files with changes. [dependabot skip]"

- name: Push changes
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason to separate these steps or could they be combined into one step. Also, if something were to fail at this point, can we provide good feedback in the workflow?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have any strong preference here, but thought splitting the commands into individual steps would make it more clear where a failure occurred.

What type of feedback would you like to see? Right now, it will display the full error message as returned by Git.

@desrosj desrosj marked this pull request as ready for review March 13, 2025 15:09
@github-actions
Copy link

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props desrosj, johnbillion, joemcgill.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

@desrosj
Copy link
Member Author

desrosj commented Mar 14, 2025

I've gone and created a GitHub App and configured it as required for this to work. Let's give it a try!

@github-actions
Copy link

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

  • The Plugin and Theme Directories cannot be accessed within Playground.
  • All changes will be lost when closing a tab with a Playground instance.
  • All changes will be lost when refreshing the page.
  • A fresh instance is created each time the link below is clicked.
  • Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
    it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

@desrosj desrosj added the props-bot Adding this label triggers the Props Bot workflow for a PR. label Mar 14, 2025
@github-actions github-actions bot removed the props-bot Adding this label triggers the Props Bot workflow for a PR. label Mar 14, 2025
desrosj added 2 commits March 14, 2025 14:53
…uilt-files

# Conflicts:
#	.github/workflows/check-built-files.yml
#	.github/workflows/reusable-check-built-files.yml
@desrosj
Copy link
Member Author

desrosj commented Mar 14, 2025

Hmm, there's something different between my fork where I tested and wordpress-develop. I've configured everything the same way, but the token is unable to checkout the repository and I'm not sure why.

I've gone and disabled the workflow until someone is able to figure out why.

@desrosj
Copy link
Member Author

desrosj commented Mar 17, 2025

So this is an issue with PRs coming from forks, which I couldn't test in my own fork.

There are two issues:

  • The workflow is checking out WordPress/wordpress-develop, not the repository the PR originates from.
  • The ref is set to trunk because pull_request_target workflows originate from the base branch.

Adjusting the inputs for the actions/checkout step to the following should fix the issue, but there's no way of knowing until it's committed.

repository: ${{ github.event.pull_request.head.repo.full_name }}
ref: ${{ github.event.pull_request.head.ref }}

The only unknown here is whether the GitHub App will be able to act in the same manner as maintainers, given the PR author has checked "Allow edits and access to secrets by maintainers".

@desrosj
Copy link
Member Author

desrosj commented Mar 21, 2025

Closing out. This is committed and seems to be working well. Will monitor and open separate PRs if necessary.

@desrosj desrosj closed this Mar 21, 2025
@desrosj desrosj deleted the add/workflow-for-built-files branch March 21, 2025 18:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants