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
Update repository declaration order #17101
Conversation
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.
Thanks!
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.
Could you explain the rationale here? Do I misunderstand or we will always try to download things instead of using the local cache?
✖ This workflow run has failed but no jobs reported an error. Something weird happened, please check the workflow run page carefully: it might be an issue with the workflow configuration itself. |
Well not exactly. Errors come from the fact that some artifacts are only partially resolved in the local repository (only the pom is present and not the jar). In that case, gradle don't fallback to the next repository to resolve the Regarding the resolution, gradle also have a cache for dependencies, dependencies will only download once if they are not already in that cache. I agree that this is not a durable solution but this avoid to disable those tests. |
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
ok, so this won't change. gradle/gradle#17144 (comment) |
@famod looks like there's an issue with the build: |
@gsmet The script is not yet covering this case which was introduced recently: 9bd76ca#diff-307c72aded80fc768e1f20cfa0bed2320c3fe4bb815a6996db89d986c972d845 |
So I broke it, cool :) The thing is that I had no idea I broke it. Would it be possible to fail the job if something is wrong? |
@geoand Thing is that in your PR GIB decided to do a full build due to:
and because of that the respective part of the script wasn't run at all (no use filtering any native jobs for a full build). Nice corner case you hit there! I'll think about making this more fine grained: https://github.com/quarkusio/quarkus/blob/main/pom.xml#L290 |
This fix change the order of repository declaration in sample test projects.
It should fix release test ci job and tests that fail in PRs.