#52653 closed task (blessed) (fixed)
Run GitHub Action workflows for testing old branches on a schedule
Reported by: | desrosj | Owned by: | desrosj |
---|---|---|---|
Milestone: | 5.8 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Build/Test Tools | Keywords: | has-patch |
Focuses: | Cc: |
Description
On TravisCI, the tests for each old branch would run periodically on a cron to ensure that they continue to pass as time progresses, even when changes are not made on a regular basis.
The schedule looked like this:
- Daily for the currently supported minor version.
- Weekly for the next oldest version.
- Monthly for all other older branches.
These crons would not run if the branch had a build within the last 24 hours.
This is a bit difficult to accomplish with the way GitHub Actions currently work. Though there is a schedule
event that triggers workflow runs, it only works within the primary branch.
There is a `workflow_dispatch` event that allows manually triggering workflows, which is supported in the REST API.
Attachments (1)
Change History (39)
This ticket was mentioned in PR #1044 on WordPress/wordpress-develop by desrosj.
4 years ago
#1
- Keywords has-patch added
4 years ago
#2
Besides the personal access token I would need to configure, I think this is in a good spot. But, I'm not sure how we'd be able to test it without adding the workflow_dispatch
trigger to an older branch. Then we could change this new workflow to run on pull_request_target
, and see if it is triggered successfully. Otherwise I don't think this will run.
#3
@
4 years ago
I have a proof of concept working over on my fork, but for some reason two of the workflows are not triggering correctly, despite having workflow_dispatch
. When I dispatch the event by manually sending a curl
request, the workflow triggers successfully.
I've opened an issue upstream to see if the action maintainer has any thoughts. That option is much cleaner, so I'd prefer to use that over crafting our own curl
requests.
4 years ago
#5
I've gotten this working by using the actions/github-script
action and the workflow_dispatch
event.
Here's how I've tested:
- Created a branch off of
5.5
called5.5-test
. - Added the
workflow_dispatch
event to each workflow in that test branch. - Added the
pull_request
trigger event to the new,test-old-branches.yml
file. - Opened a PR for my fork to merge this branch and trigger the workflow with a paired down list of versions.
- Observed manual runs dispatched for the `5.5-test` branch for each workflow.
- Polished theworkflow and pushed again to confirm all branches receive jobs for their appropriate workflows.
One downfall of manually dispatching workflows is that the branch does not display to the right of the workflow like push
or pull_request
events. But, they do show when filtering by branch, and after clicking into a workflow, you can click the SHA value to see the commit the workflow was triggered for (it will always be the most recent commit within the branch). This is a GHA limitation, though. I was unable to find any way to change the workflow name, or display more information on the run.
Previously on TravisCI, the older branches ran monthly and more recent ones weekly. This runs them all weekly. There was also a setting to only run scheduled builds if there had not been one run in the previous 24 hours for a branch. That has also not been copied over.
johnbillion commented on PR #1044:
4 years ago
#6
Is there a need for the current branch (currently 5.7) to be included in this matrix?
4 years ago
#7
The schedule event trigger will only work in the primary branch. If 5.7 is not included, it would only be tested if a commit is made.
#9
@
3 years ago
- Keywords fixed-major added
- Resolution fixed deleted
- Status changed from closed to reopened
Reopening to backport.
This ticket was mentioned in Slack in #core by sergey. View the logs.
3 years ago
3 years ago
#32
Merged into Core in https://core.trac.wordpress.org/changeset/50590.
#34
@
3 years ago
- Keywords fixed-major removed
This week the first scheduled run of this workflow occurred: https://github.com/WordPress/wordpress-develop/actions/runs/707069966.
Branches 3.7, and 4.9-5.7 all were tested successfully (the other branches did not have the required changes to be run). Here are some notes.
The workflow was scheduled for the first of the month at 00:00 UTC. When jobs are scheduled, GitHub takes all of the jobs with the same scheduled time and places them in a pool and they are run as resources are available. This resulted in the workflow actually starting at ~02:34. This delay is not a huge deal, but it's worth noting it's not always immediate.
The next scheduled run is on the 15th at 00:00 UTC. After that occurs, I think that 52653.diff should be committed to do a few things.
First, it splits the two scheduled dates into two separate crons. This allows us to detect which day it is (1st or 15th).
Second, it introduces a conditional statement using the separate crons above to only test the two most recent branches twice per month, and all other branches once per month. This more closely matches our testing setup on Travis, and prevents some needless testing.
And finally, because an overwhelming number of projects are most likely running workflows at 00:00 on the 1st, it changes all branches to being tested on the 15th, and only the 2 most recent on the 1st.
This ticket was mentioned in Slack in #core by sergey. View the logs.
3 years ago
This ticket was mentioned in PR #1194 on WordPress/wordpress-develop by desrosj.
3 years ago
#36
Trac ticket:
3 years ago
#38
Merged into Core in https://core.trac.wordpress.org/changeset/50763.
Trac ticket: https://core.trac.wordpress.org/ticket/52653.