Initial implementation of rightmost bumps#393
Open
pemensik wants to merge 6 commits into
Open
Conversation
pemensik
force-pushed
the
main-rightmost-bumps
branch
from
170607e to
80f373a
Compare
Author
|
This is attempt to implement #328 |
pemensik
force-pushed
the
main-rightmost-bumps
branch
from
80f373a to
8856e4b
Compare
Author
|
Fixed tests on my machine. The only remaining problem is not 100% test coverage. Additional changes support also bumping to z-stream (minor bump) style by |
pemensik
force-pushed
the
main-rightmost-bumps
branch
from
ccb8ebf to
cd4286c
Compare
Author
|
@nphilipp would you please have some time to review this attempt? This should fix common problem for centos packagers. |
Adds new magic comments supported in commits: [bump_rightmost: 3] [start_rightmost] This should implement missing z-stream type bumps used mainly in RHEL already released branches fixes. It is needed to ensure latest branch build is always preferred after upgrade to higher version. In Fedora regular mass rebuilds mitigates the need for something similar. But it could be still used when doing rebase in multiple branches, where only rawhide build should always have highest release. This is attempt to provide user-friendly alternative to manual calls of rpmdev-bumpspec -r command. Signed-off-by: Petr Menšík <pemensik@redhat.com>
Generate extra lua code on the right side of release too. Print
rightmost numbers where it belongs, after %{?dist} tags on normal usage.
Adds -r parameter to %autorelease, which increases minor bump base
instead.
Signed-off-by: Petr Menšík <pemensik@redhat.com>
Signed-off-by: Petr Menšík <pemensik@redhat.com>
Make smarter recognition of magic strings. Log unrecognized magic strings as a warning. When it requires bump value number, say it is known but wrong type. Report completely unsupported magic strings. Signed-off-by: Petr Menšík <pemensik@redhat.com>
Implement some magic strings testing. Filter magic strings read from yaml, create MagicCommentResult directly from yaml. Signed-off-by: Petr Menšík <pemensik@redhat.com>
Add documentation for new functionality. Signed-off-by: Petr Menšík <pemensik@redhat.com>
pemensik
force-pushed
the
main-rightmost-bumps
branch
from
bc53786 to
c43e181
Compare
Author
|
Anyone for review? |
Contributor
|
I'll try to perform a review next week. I don't have time today and tomorrow is a holiday in the US. Sorry about this; it completely slipped off the radar. |
Author
|
okay, does not have to be finished next week, but some comments whether it could work this way would be nice. |
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Adds new magic comments supported in commits:
[bump_rightmost: 3]
[start_rightmost]
This should implement missing z-stream type bumps used mainly in RHEL already released branches fixes.
It is needed to ensure latest branch build is always preferred after upgrade to higher version. In Fedora regular mass rebuilds mitigates the need for something similar. But it could be still used when doing rebase in multiple branches, where only rawhide build should always have highest release.