Closed atc0005 closed 1 year ago
PRs opened in all applicable projects.
I will need to go back and review the CI results once all jobs complete and merge before closing this GH issue.
PRs opened in all applicable projects.
I will need to go back and review the CI results once all jobs complete and merge before closing this GH issue.
Done.
Overview
While reviewing an offered Pull Request for a project that I maintain, I found some of the CI failures to be unclear.
Example:
Looking at other jobs I realized what the real problem was:
The contributor was adding a dependency to the project (
stretchr/testify
for their test cases), but did not vendor the dependency before submitting their PR.The current CI failures do not indicate that this is expected.
The
go mod tidy
andgo mod vendor
checks are handled here:This job is included by importing workflows like this one:
The end result is that these steps only run for code pushed to a branch that lives in the project's repo. As I'm the primary contributor to projects that I maintain and am the sole contributor pushing to branches in those repos I didn't catch this "gotcha" until this most recent PR.
I'll plan to either mirror the jobs (duplication), or (more likely) import the
quick-validation.yml
file into another workflow file so that thego mod tidy
andgo mod vendor
steps run early in the CI jobs process when Pull Requests are submitted.As of this moment I'm not sure how to pull that off (cleanly) without touching the workflow files in each project (which I was hoping to prevent).
TODO
Update each project's copy of the
project-analysis.yml
file to include two additional jobs:This enables the following steps:
By adding these jobs to the existing project-analysis.yml workflow file they're executed on Pull Requests (new, updated) and on the existing weekly schedule.
The expected runtime impact is low.
Along with these changes is the need to update the existing "Branch protection rule" for this project. GH-52 will track that work.
References