tickets #102981
open
update_release_notes script doesn't handle errors very well
Added by cboltz over 2 years ago.
Updated about 2 years ago.
Category:
Servers hosted in NBG
Description
I tried adding the 15.3 release notes to salt/profile/documentation/files/releasenotes, but manually testing it ended up with an interesting[tm] error:
# /home/relsync/bin/update_release_notes
Could not find a valid RPM at https://build.opensuse.org/public/build/Documentation:Auto/openSUSE_Leap_15.3/x86_64/_repository/release-notes-openSUSE after 3 attempts - giving up.
error: open of <status failed: No such file or directory
error: open of code=404> failed: No such file or directory
error: open of <summary>no failed: No such file or directory
error: open of such failed: No such file or directory
error: open of binary failed: No such file or directory
error: open of release-notes-openSUSE</summary> failed: No such file or directory
error: open of <details>404 failed: No such file or directory
error: open of no failed: No such file or directory
error: open of such failed: No such file or directory
error: open of binary failed: No such file or directory
error: open of release-notes-openSUSE</details> failed: No such file or directory
error: open of </status> failed: No such file or directory
- Private changed from Yes to No
- Assignee changed from lrupp to cboltz
Dunno why this is assigned to me?
Isn't that a problem for RelMgr or Doc-Team?
- Assignee changed from cboltz to lrupp
I can explain that ;-)
head salt/profile/documentation/files/update_release_notes
[...]
# Copyright (C) 2013-2014, SUSE Linux Products GmbH
# Copyright (C) 2015-2016, SUSE Linux GmbH
# Author: Lars Vogdt
You are the original author of that script, therefore I hope you know how to fix it.
(Feel free to reassign to someone with more knownledge, but I'm afraid I don't fall under this definition.)
- Status changed from New to Feedback
- Assignee changed from lrupp to cboltz
cboltz wrote:
You are the original author of that script, therefore I hope you know how to fix it.
well, years ago...
If you can tell me where this script is currently running, I might have a look... ;-)
At the moment, I feel a bit lost by getting some misterious debug output and just the header of a script I probably wrote 5(?) years ago.
- Status changed from Feedback to New
- Assignee changed from cboltz to lrupp
lrupp wrote:
If you can tell me where this script is currently running, I might have a look... ;-)
At the moment, I feel a bit lost by getting some misterious debug output and just the header of a script I probably wrote 5(?) years ago.
I admit that I quoted the most evil lines - those pointing in your direction ;-))
The script is running on pinot.i.o.o in /home/relsync/ as user relsync (via cron).
For setup details, see salt/profile/documentation/ - the salt code is in release-notes.sls, the script and its config file in the files subdirectory.
I can at least explain the mysterious output: It looks like the script gets a 404 page, interpretes each word in that 404 page as a filename, and then tries to open all these "files".
- Status changed from New to Workable
- % Done changed from 0 to 10
cboltz wrote:
Looking at http://download.opensuse.org/repositories/Documentation:/Auto/openSUSE_Leap_15.3/noarch/ I'd guess the problem is that nowadays the RPM filename is release-notes-openSUSE-L153-15.3.20220130.832685eb-lp153.201.1.noarch.rpm (note the added -L153), but I'm not sure about the correct config file syntax.
The name of the package is clearly problematic. I asked the maintainer in a comment in OBS why this rename has happened without any prior notice.
Let's wait and see his answer, before we start touching the infrastructure.
Hello!
I confess to being the person who changed the RPM name. The reason was that I misconfigured one of the OBS repos for Leap RN once and then the output RPMs overwrote each other in not-so-predictable ways. Adding an explicit version number suffix to the OBS repo name/RPM name seemed like a good idea at the time.
We actually have the script & config on GitHub as well and usually sync from there (or at least I did in the past): https://github.com/openSUSE/doc-o-o/tree/main/rn-config
The script in the Git repo is fixed and generates RPM with both the old and the updated file name.
- Assignee changed from lrupp to cboltz
stfnknorr wrote:
We actually have the script & config on GitHub as well and usually sync from there (or at least I did in the past): https://github.com/openSUSE/doc-o-o/tree/main/rn-config
The script in the Git repo is fixed and generates RPM with both the old and the updated file name.
Thanks for your input!
I guess the main problem was the configuration issue in the 'releasenotes' file. The one on pinot did not had the correct RPM name ending for 15.3 (and 15.2), so the script went crazy.
I decided to take a quick look at the script anyway and created the following PR in Github: https://github.com/openSUSE/doc-o-o/pull/20
Can I ask you to please have a look and merge it, if I did not make too many mistakes?
To my defense, I tested the changes already in production.
@Christian: IMHO it might make sense to checkout the script and configuration files from https://github.com/openSUSE/doc-o-o/tree/main/rn-config also on pinot, so we can stay aligned with any change. Just one note from my side here: our 'releasenotes' file goes back until Leap 42.3, while the current one in Github only cares about the still supported versions. As we probably don't get any updates for the unsupported distros any more, I tend to follow the 'releasenotes' file from 'upstream' here as well. To our luck, there is currently no global index.html (https://doc.opensuse.org/release-notes/) file to adjust and the old directories and files will just stay, as there is also no cleanup. => assigning to you for GIT/Salt/KungFu magic. If you don't have time, just re-assign to me.
I decided to take a quick look at the script anyway and created the following PR in Github: https://github.com/openSUSE/doc-o-o/pull/20
Thank you!
However, I am not really sure what the best way to proceed with this would be. It seems like a bad idea to maintain the script/config twice.
- Can Salt just use the version from the doc-o-o repo (=that would be the most transparent solution for the doc team)?
- Alternatively, we should just delete the config/script from the doc-o-o repo, but that would leave all maintenance squarely with the oS Heroes.
Fyi -- the script/config from the doc-o-o repo is currently syncable via the repo's Makefile: make upload_rn_config.
[...] and the old directories and files will just stay [...]
Should any of them ever get lost, hellcp has started this repo: https://github.com/openSUSE/legacy-release-notes/
I am not sure if there's any kind of automated backup in place, you'd have to ask him but probably not.
Also available in: Atom
PDF