-
Notifications
You must be signed in to change notification settings - Fork 311
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Differentiate scheduled 2.x job cache from main cache #906
Conversation
Kudos, SonarCloud Quality Gate passed! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
Side question: Why do we even have the integrationTests-2.x.yaml
? Is it not possible to include the 2.x branch in the main integrationTests.yaml
?
It's for the scheduled job, so the right branch is checked out. The non-scheduled PR/branch integration tests are handled with the regular configuraion. |
Yes; because this documentation for non-scheduled events "When using the pull_request and pull_request_target". Pull requests (by way of branch pushes) are already handled by the standard However, if you look at on.schedule documentation, it says "Scheduled workflows run on the latest commit on the default or base branch. ". So it's not possible to run a scheduled task on a different branch, and the only way to run integration tests on Here are some relevant github threads: |
@elefeint Thanks for the refs. What I was also thinking was along the lines of using the matrix. See this comment: https://g.nite07.orgmunity/t/scheduled-builds-of-non-default-branch/16306/14. |
That's something we could certainly do, as long as the new matrix dimension makes it into the cache key. Do you want to send a PR? |
I think one of the reasons the flakes got more frequent is that the 2.x unit/integration tests run first, and set up the older set of artifacts. Then all the new code (
main
branch and PRs off of it) has to re-download Spring Boot 2.6-related artifacts on the fly.This PR makes 2.x unit and integration tests use different caches.
After this if, once we start backporting changes to 2.x, we notice that 2.x flakes more than
main
, it will be confirmation of this hypothesis.