w3c
Infrastructure: Update `examples.yml` to update the coverage report's last updated date if needed
Following the merge of #2122 and the inclusion of a "Page last updated" field on the coverage and quality report page, there is a surety that the examples.yml's coverage: job will fail on main if a PR triggering examples.yml is merged on a date after what has already been set in the PR.
This is due to a failing diff check caused by the more recent date being generated by npm run coverage-report when the PR is merged into main: examples.yml#61-62
As a request of yesterday's APG meeting, this PR will capture any changes found in that coverage report's diff check and immediately push it to the main branch because the "last updated date" should reflect when the affecting PR is merged in.
An example of the update commit message:
chore: update coverage report page's last updated date Generated by commit_id
(To keep in line with the structure of other commits pushed to this repository by github-actions[bot])
WAI Preview Link (Last built on Mon, 26 Feb 2024 16:38:26 GMT).
@mcking65 the reason the last updated date can’t be done in the same way the example pages are when deployed to WAI, is because the build repository wraps that content and includes the date in a footer based on the example's last updated git date.
So a potential alternative to do the same thing here, is for the build repository to be updated to include a new transform for the coverage report, and slot the date into the same position at the top of the coverage report template. But this will also mean there isn’t a need to update that date in this repository.
@howard-e I am OK with this approach for this week's publication.
I had a different approach in mind. However, what I am thinking might not make sense b/c I don't think I fully grasp how the GH workflows work. Just in case this is a workable idea, here it is ...
Is it possible for the merge process to trigger a workflow that runs the coverage report script just before the merge is made?
Another possibility is for the coverage report script to use a different date, instead of runtime date, that would be the same both on the day that the last commit was pushed to the compare branch and on the day the compare branch is merged. Perhaps that could be the date of the last commit in the compare branch?
@mcking65 said:
Is it possible for the merge process to trigger a workflow that runs the coverage report script just before the merge is made?
This happens locally on a contributor's device using a husky pre-commit which runs npm run-coverage with lint-staged before a commit is pushed. This still has the potential date desync when the PR is pushed on a later date however to main. And even more so, if a commit is able to bypass the pre-commit hooks with --no-verify.
Another possibility is for the coverage report script to use a different date, instead of runtime date, that would be the same both on the day that the last commit was pushed to the compare branch and on the day the compare branch is merged. Perhaps that could be the date of the last commit in the compare branch?
@mcking65 agreed! I've updated the code to reflect that in coverage-report.js (the same would have been done in the transform).
It would still raise the same problem of the main branch needing to update itself if done after the date the PR last updated, if merged into main with a squash and merge commit, so I've left the workflow change in for now.
@mcking65 All builds are now passing here if we'd like to go ahead with pushing this.
But there is a new date related regression test issue which seems unrelated to this PR as I can replicate it on main and seems to have only started happening. I've filed #2938 to track it.