[opensuse-buildservice] OBS Maintenance Process - How to release a maintenance update to different codestream? - openSUSE Build Service

newer
[opensuse-buildservice] Disable an...

[opensuse-buildservice] OBS Maintenance Process - How to release a maintenance update to different codestream?

Srinidhi B

10 Jul 2019 10 Jul '19

09:37

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: * Packages should not be rebuilt in codestream Y * Binaries should not be signed again I've written a script that does the following: 1. Run cmd=createmaintenanceincident on the Maintenance project to create a new incident 2. Create "patchinfo" package 3. Update patchinfo/_patchinfo - based on a very slightly modified version of code taken from obs_admin --create-patchinfo-from-updateinfo - enable build and publish manually (I'm yet to figure out how to create proper hash for enabling these at the package creation time) 4. Branch Channel package - osc branch -M <Channels-prj> <channel-pkg> <maintenance-incident> 5. Enable channel - osc enablechannel <maintenance-incident> <channel-pkg> 6. Upload / inject binaries and updateinfo.xml fetched from step 3 to "patchinfo" package What I found while talking to Adrian on IRC, I can't raise a release request for such a maintenance incident because the API can't find a package other than "patchinfo" in "succeeded" state. And even if I use _aggregates for these packages, then also, I can't raise a release request because "patchinfo" package is always "excluded" saying "no package enabled". How do I go about re-releasing a maintenance update? Regards, Srinidhi. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

Show replies by date

Marcus Meissner

10 Jul 10 Jul

09:57

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?

...

* Packages should not be rebuilt in codestream Y * Binaries should not be signed again

I've written a script that does the following:

1. Run cmd=createmaintenanceincident on the Maintenance project to create a new incident 2. Create "patchinfo" package 3. Update patchinfo/_patchinfo - based on a very slightly modified version of code taken from obs_admin --create-patchinfo-from-updateinfo - enable build and publish manually (I'm yet to figure out how to create proper hash for enabling these at the package creation time) 4. Branch Channel package - osc branch -M <Channels-prj> <channel-pkg> <maintenance-incident> 5. Enable channel - osc enablechannel <maintenance-incident> <channel-pkg> 6. Upload / inject binaries and updateinfo.xml fetched from step 3 to "patchinfo" package

What I found while talking to Adrian on IRC, I can't raise a release request for such a maintenance incident because the API can't find a package other than "patchinfo" in "succeeded" state. And even if I use _aggregates for these packages, then also, I can't raise a release request because "patchinfo" package is always "excluded" saying "no package enabled".

How do I go about re-releasing a maintenance update?

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. Check if the channels are in the correct channels with "osc ls -b" or similar. then do a releaserequest again osc releaserequest $INCIDENT check with "rq show" if its correct. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

Srinidhi B

10:10

Hello Marcus, Thank you for responding!

...

...
...
On Wednesday, 10 July, 2019 at 03:27 PM, Marcus Meissner 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

Srinidhi B

11 Jul 11 Jul

07:53

Hello Again, In the project meta of a maintenance incident, we usually have **something like**: <releasetarget project="SUSE:Updates:<PRODUCT>:x86_64" repository="update" trigger="maintenance"/> If I change trigger="maintenance" to trigger="manual", will I be able to release the maintenance update by running the following command? $ osc api -X POST '/source/Maintenance:XX/patchinfo?cmd=release&target_project=SUSE:Updates:<PRODUCT>:x86_64&repository=<repository-from-incident>&target_repository=update' Why I'm asking this specifically is whether this would trigger the workflow of updating package tracking information and copying the binaries, etc.? Regards, Srinidhi.

...

...
...
On Wednesday, 10 July, 2019 at 03:40 PM, Srinidhi B wrote: Hello Marcus,

Thank you for responding!

...
...
...
On Wednesday, 10 July, 2019 at 03:27 PM, Marcus Meissner 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

Marcus Meissner

08:27

On Thu, Jul 11, 2019 at 01:53:26AM -0600, Srinidhi B wrote:

...

Hello Again,

In the project meta of a maintenance incident, we usually have **something like**:

<releasetarget project="SUSE:Updates:<PRODUCT>:x86_64" repository="update" trigger="maintenance"/>

If I change trigger="maintenance" to trigger="manual", will I be able to release the maintenance update by running the following command?

$ osc api -X POST '/source/Maintenance:XX/patchinfo?cmd=release&target_project=SUSE:Updates:<PRODUCT>:x86_64&repository=<repository-from-incident>&target_repository=update'

Why I'm asking this specifically is whether this would trigger the workflow of updating package tracking information and copying the binaries, etc.?

It should trigger that too, yes. 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. Ciao, Marcus

...

Regards, Srinidhi.

...
...
...
On Wednesday, 10 July, 2019 at 03:40 PM, Srinidhi B wrote: Hello Marcus,

Thank you for responding!

...
...
...
On Wednesday, 10 July, 2019 at 03:27 PM, Marcus Meissner 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

-- Marcus Meissner,SUSE LINUX GmbH; Maxfeldstrasse 5; D-90409 Nuernberg; Zi. 3.1-33,+49-911-740 53-432,,serv=loki,mail=wotan,type=real -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

Srinidhi B

09:29

Hello Marcus,

...

...
...
On Thursday, 11 July, 2019 at 01:57 PM, Marcus Meissner 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 wrote: Hello Marcus,

Thank you for responding!

...
...
...
On Wednesday, 10 July, 2019 at 03:27 PM, Marcus Meissner 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

Srinidhi B

11:50

Hello Marcus, Everyone,

...

...
...
On Thursday, 11 July, 2019 at 01:57 PM, Marcus Meissner wrote: It should trigger that too, yes.

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.

Good news is that this *actually* worked!! So thank you so much!! But the bad news is that in the "Update Channel" project, I now have a package called "patchinfo", instead of "patchinfo.XX" :-/ Does not matter whether I use "osc release" or directly using the API call I posted earlier. Looks like, for some reason, the following condition is not returning true: https://github.com/openSUSE/open-build-service/blob/2.9/src/api/app/controll... if pkg.project.is_maintenance_incident? # The maintenance ID is always the sub project name of the maintenance project target_package_name += '.' << pkg.project.name.gsub(/.*:/, '') end The project is, of course, set to maintenance incident: $ lsc meta prj Maintenance:XX <project name="Maintenance:XX" kind="maintenance_incident"> <title/> ... Apparently, the target package name (patchinfo.XX) is added whenever a releaserequest is raised. I don't see any option to do this when releasing manually. How do I rename "patchinfo" to "patchinfo.XX" safely? Only project copy supports "withbinaries" option. Create "patchinfo.XX" and inject binaries again? Regards, Srinidhi. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

Srinidhi B

15 Jul 15 Jul

09:05

Hello Everyone,

...

...
...
On Thursday, 11 July, 2019 at 05:20 PM, Srinidhi B wrote: Apparently, the target package name (patchinfo.XX) is added whenever a releaserequest is raised. I don't see any option to do this when releasing manually.

I ended up creating "patchinfo.XX" directly inside maintenance incident instead of just "patchinfo" before releasing the incident. I couldn't find any way of passing "target_package" name when POSTing to cmd=release.

...

How do I rename "patchinfo" to "patchinfo.XX" safely? Only project copy supports "withbinaries" option. Create "patchinfo.XX" and inject binaries again?

This is what I did to rename the package and inject binaries. Verified that the update channel contains binaries as well as updateinfo. Regards, Srinidhi. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

1757

Age (days ago)

1762

Last active (days ago)

List overview

Download

7 comments

2 participants

participants (2)

Marcus Meissner
Srinidhi B

[opensuse-buildservice] OBS Maintenance Process - How to release a maintenance update to different codestream?

tags

participants (2)