[opensuse-buildservice] OBS Maintenance Process - How to release a maintenance update to different codestream?
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
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
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
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 <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
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 <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
-- 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 <meissner@suse.de> -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
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
Hello Marcus, Everyone,
On Thursday, 11 July, 2019 at 01:57 PM, Marcus Meissner <meissner@suse.de> 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
Hello Everyone,
On Thursday, 11 July, 2019 at 05:20 PM, Srinidhi B <Srinidhi.BS@microfocus.com> 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
participants (2)
-
Marcus Meissner -
Srinidhi B