Hello Marcus,
On Thursday, 11 July, 2019 at 01:57 PM, Marcus Meissner <meissner@suse.de> wrote:
It should trigger that too, yes.
Thank you so much for confirming!! This is the best news I've heard / read in the last 10 days since I've been trying to wrap my head around this. One question though: My maintenance incident now looks like this: $ osc ls Maintenance:XX <PRODUCT>.Channels patchinfo As you can see, there's no "package" in this incident. Which means, no package will be copied to the "Update project". Hence, my question is - which binaries are added to binary tracking? Binaries in the "Update Channel" or binaries inside "Update project"? The reason I'm asking this is because I, preferably, do not want these binaries to be tracked.
With a manual trigger you can also use "osc relaese" with
osc release --target-repository=SUSE:Updates:<PRODUCT>:x86_64 Maintenance:XX
but in the end it will just do the above API call.
Yes. You are right! Thank you for reminding me again about this! Regards, Srinidhi.
On Wednesday, 10 July, 2019 at 03:40 PM, Srinidhi B <Srinidhi.BS@microfocus.com> wrote: Hello Marcus,
Thank you for responding!
On Wednesday, 10 July, 2019 at 03:27 PM, Marcus Meissner <meissner@suse.de> wrote: Hi Srinidhi,
On Wed, Jul 10, 2019 at 03:37:37AM -0600, Srinidhi B wrote:
Hello Everyone,
I've a question regarding OBS Maintenance Process: What is the best way to
re-release a maintenance update into a different codestream? What I mean to ask is - a maintenance update released for codestream X needs to be released
into codestream Y with following conditions:
A different product from the same built binaries?
Yes. Same built binaries to a different product line. (e.g., between base product and add-on product)
<snip/>
What we do:
osc unlock $INCIDENT the previous released incident. This will keep the package still locked.
add the new product channels (via osc addchannels or osc branch -M ... $OLDINCIDENT)
Edit the project meta:
osc meta prj -e $INCIDENT
remove trigger="maintenance" XML attributes from the repos that should
NOT
be rereleased.
Thank you for sharing these steps! I was aware of some of these steps, but
this trigger="maintenance" is new to me. Will add this to my notes!
But unfortunately, I don't have access to the old incident because the re-release will happen across Build Service instances. This is why, we can't use this approach and we need to import these updates into our instance of
Build Service.
Regards, Srinidhi.
-- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org