-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Update pom file version scanner #39221
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
Conversation
|
/azp run prepare-pipelines |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
API change check API changes are not detected in this pull request. |
…brary from the track2's yml file
billwert
left a comment
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.
Couple questions but otherwise looks good to me.
|
/azp run java - azure-identity-extensions |
|
Azure Pipelines failed to run 1 pipeline(s). |
…y of com.microsoft.azure:azure-eventhubs-eph
…java into UpdateVerScan
|
I'm going to override check-enforcer. The reason being is that the latest-jdk.yml had to be updated for the generate_from_source_pom argument changes. If these changes were going to cause a failure, it would have happened long before the run tests step even started and latest-jdk.yml takes 2 hours to run. |
|
/check-enforcer override |
The primary reason for this PR was that I'd found, by happenstance, a number of issues where dependency tags, weren't correctly set.
The pom_file_version_scanner now figures out, by using the ci*.yml files, what builds in each sdk/ and verifies that any tags appropriately. To quickly reiterate the rules:
For most service directories, the updates consisted of adding the correct additional modules and/or correctly setting tags. There were two special cases that required new pipelines to be created. The reason being is that these need to use the dependency versions of the libraries in their respective service directories because they're not released with the same cadence and have different owners than the service directory owner. As such, the ci.yml file for their pipelines was created in the library's subdirectory. We already do this in sdk/communication since each library is owned by a different team.