ci: Introduced vetting test on PRs and corrected package version to match "current state of the package" #3549
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
michalChrobot
requested review from
NoelStephensUnity,
EmandM and
a team
as code owners
|
We can land this after 2.5.0 release so we are "up to date" |
|
FYI I included an improvement of release.py to address MTT-12840 and make the package "release ready" with running this script. I'm waiting for 2.5.0 to be released first |
michalChrobot
added a commit
that referenced
this pull request
Jul 31, 2025
…ersion to match "current state of the package" (#3550) This PR is a backport of #3549 and introduces vetting test that should be running on PR to confirm that the package will be in "releasable state". Things to note are ## Bumping package version After N4E investigation in I noticed that vetting tests were not working properly because after each release we should bump package version to match "current state of the package" which means bumping it by a patch. That way the current package version is being compared against last released. Otherwise this test won't give us any valid result because we will be comparing 2 already released packages. Because of that I bumped NGO internal version to 2.5.0 and in that way we will be comparing this "current" version against last released 2.4.3 ## What this test will do This test will mostly evaluate API compatibility. What we want to achieve is to not release any new minor version if not needed/detect all new APIs earlier. Notice that this test will fail if any new API is introduced (because for new API we need to release new minor and not patch) and in such scenario we should either - Bump package version to new minor, indicating that we will release new minor version - Make the API internal/private This will ensure that we know the current state of the package version. Notice that in theory we could also use wrench/api-validation test but this would require manually modifying this file after every wrench update (to add release.py execution) so easier approach will be to create a dedicated test and leave wrench one for actual release validation ## release.py script This python script is basically copied from N4E repo and updates CHANGELOG and any other places that need to be formatted for the release. For now it's only used for this test (to avoid it throwing an error about CHANGELOG being improperly formatted) but in the future we can use it to automate releasing ## Backport #3549
|
Ok, since we are not 100% sure when we will land 2.5.0 I decided to just merge this PR so I can proceed with automations. I corrected the package version to |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR introduces vetting test that should be running on PR to confirm that the package will be in "releasable state". Things to note are
Bumping package version
After N4E investigation in I noticed that vetting tests were not working properly because after each release we should bump package version to match "current state of the package" which means bumping it by a patch. That way the current package version is being compared against last released. Otherwise this test won't give us any valid result because we will be comparing 2 already released packages.
Because of that I bumped NGO internal version to 2.5.0 and in that way we will be comparing this "current" version against last released 2.4.3
What this test will do
This test will mostly evaluate API compatibility. What we want to achieve is to not release any new minor version if not needed/detect all new APIs earlier. Notice that this test will fail if any new API is introduced (because for new API we need to release new minor and not patch) and in such scenario we should either
This will ensure that we know the current state of the package version. Notice that in theory we could also use wrench/api-validation test but this would require manually modifying this file after every wrench update (to add release.py execution) so easier approach will be to create a dedicated test and leave wrench one for actual release validation
release.py script
This python script is basically copied from N4E repo and updates CHANGELOG and any other places that need to be formatted for the release. For now it's only used for this test (to avoid it throwing an error about CHANGELOG being improperly formatted) but in the future we can use it to automate releasing
Backport
#3550