cranky: close: Fix base_version calculation for respins in 4/2 cycle
Due to 4/2 cycle, in case we need to respin both security main kernel
and sru main kernel, we end up with interleaving versions:
security spin-1: 6.2.0-11.11
sru spin-1: 6.2.0-12.12
security spin-2: 6.2.0-13-13
sru spin-2: 6.2.0-14.14
When cranky close is run for a derivative in the security cycle, both
spin-1 and spin-2 changes are there, but for the sru cycle, only spin-2
changelog (6.2.0-14.14 in this case) are there, instead of both spin-1
and spin-2. This happens because we look for the latest parent tag present in
the changelog (in this case it's the security spin-2: 6.2.0-13.13) and
the changelog is calculated from there.
This commit addresses this issues, and should work correctly for cases
like this, but also normal case where just a spin-1 is present.
We find the latest derivative tag and we check the common ascensor
between HEAD and this tag which should result in the master version of
sru-spin-1.
This only works for direct directives from master, therefore the old
implementation is left for second level derivatives.
Note: The latest tag is calculated based on changelog, not by using `git
tag` command, so that we could test it easily
with previous versions and it would not interfere with newer tags
already created. For backports, '~' is replace with '_'.
cranky: promote-snap -- add support for promoting by tracker
Add support for promotion by tracker number. As things stand
you have no way to perform the promotions wanted for a stream#1 tracker
and not a stream#2 tracker. Add support for promoting by tracker to
simplify selection.
Signed-off-by: Andy Whitcroft <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Signed-off-by: Andy Whitcroft <email address hidden>
annotations: update: properly update note for arch-flavour configs
Values in the form "arch-flavour" are incorrectly processed in the logic
to determine if the note needs to be updated, causing a bunch of notes
to be incorrectly replaced with 'TODO: update not'.
Fix this by searching the values with the proper arch and flavour.
== Additional notes ==
Inside the affected function we are replacing flavour with "arch-flavour" to easily access the items in the dictionary `self.config[conf]['policy']`.
But we also used the replaced flavour variable to search for the old value (and trigger the "update note" condition), that ended up being replaced another time, producing "arch-flavour-flavour", that is incorrect.
This is why all the notes for the values in the form "arch-flavour" were incorrectly replaced with the "TODO", because it was always failing to find the previous value.
Signed-off-by: Andrea Righi <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Signed-off-by: Andrea Righi <email address hidden>
annotations: update: properly update note for arch-flavour configs
Values in the form "arch-flavour" are incorrectly processed in the logic
to determine if the note needs to be updated, causing a bunch of notes
to be incorrectly replaced with 'TODO: update not'.
Fix this by searching the values with the proper arch and flavour.
Signed-off-by: Andrea Righi <email address hidden>
