#271 Add releng commands to template
Closed a year ago by kparal. Opened 2 years ago by kevin.
fedora-qa/ kevin/blockerbugs more-simple-releng-commands  into  develop

@@ -11,6 +11,10 @@ 

  * [{{ update.title or update.updateid }}]({{ update.url }}) for {%- for bug in update.bugs if bug.milestone_id == milestone and (bug.accepted_blocker or bug.accepted_0day or bug.accepted_fe) %} [#{{ bug.bugid }}]({{ bug.url }}){% endfor %}

  {%- endfor %}

  

+ == Releng commands ==

+ Remeber to untag all builds in fN-compose

+ koji tag-build fN-compose {% for update in fe_updates %}[{{ update.title or update.updateid }}] {%- endfor %} {% for update in blocker_updates %}[{{ update.title or update.updateid }}]{%- endfor %}

+ 

  

  ### FREEZE PUSH ###

  
@@ -25,6 +29,9 @@ 

  {%- endfor %}

  {% endautoescape %}

  

+ Make sure all builds are pending stable

+ sudo -u apache bodhi-push --builds {% for update in fe_updates %}[{{ update.title or update.updateid }}] {%- endfor %} {% for update in blocker_updates %}[{{ update.title or update.updateid }}]{%- endfor %}

this is wrong. it lists every blocker/FE-fixing build, even ones in updates that aren't queued for stable. It needs to only include updates where update.request == 'stable', just like the other existing FREEZE PUSH blocks.

+ 

  

  {% if bugs_with_deps -%}

  ### THE ABOVE MIGHT NOT BE COMPLETE - CHECK BUG DEPENDENCIES ###

Right now we have to copy and paste things from the ticket, which is
error prone and anoying. So, how about we just include the commands
releng folks would run here with all the builds populated. This allows
us to only have one line to copy out for each thing.
Also include reminders to untag previous compose items.

We may have to tweak this some, but I think it's mostly right
(I don't have a great way to test it, perhaps we could push to staging?)

Signed-off-by: Kevin Fenzi kevin@scrye.com

@kevin It's now deployed on staging, can you create some bodhi updates for the blockers there? Or shall I take a look at the stg bugzilla if there has been a sync with newer bugs?

Kevin, how much do you wish to have this deployed in production before F38 Final? I understand it makes most sense to have this ready now, but we're also in a rush so shortly before Final. If this can wait and be included for the F39 cycle, I'll look at it after F38 is out and test it properly locally or on staging. Currently, staging contains old data and is not really useful for testing this.

Kevin, how much do you wish to have this deployed in production before F38 Final? I understand it makes most sense to have this ready now, but we're also in a rush so shortly before Final. If this can wait and be included for the F39 cycle, I'll look at it after F38 is out and test it properly locally or on staging. Currently, staging contains old data and is not really useful for testing this.

I think Kevin wanted this on purpose for f38 releng jobs on the compose. This is trivial enough PR we can cherry-pick and pull it into production without too much trouble, there is no need to wait for after the release.

@kevin deployed on production instance 😎

It's nice to have... it's not urgent, it just makes things easier. If it's not there, we will just do it more manually. ;)

Thanks will check it out and we can adjust it as we go?

So, it looks mostly good, just a few minor things:

  • Need to remove the [s and ]s around the updates/builds in both lists.

  • Is there some way to get the current release? then we could change:

Remeber to untag all builds in fN-compose
koji tag-build fN-compose [fedora-toolbox-38-14] 

to something like:

for i in `koji list-tagged f38-compose --quiet | awk '{print $1}'`
do
     koji untag-pkg f38-compose $i
done
koji tag-build f38-compose fedora-toolbox-38-14

@kevin deployed on production instance 😎

I'm not exactly happy to have code which doesn't pass unit tests deployed in production directly before Final RCs. But I leave it up to you, Frantisek. In any case, please keep it just as a local patch without committing it to master, thanks.

@kevin deployed on production instance 😎

I'm not exactly happy to have code which doesn't pass unit tests deployed in production directly before Final RCs.

And I love it 😅 ! (actually, did you check the failure and the failing test?)

But I leave it up to you, Frantisek. In any case, please keep it just as a local patch without committing it to master, thanks.

Yep, as it is now ;)

So, it looks mostly good, just a few minor things:

  • Need to remove the [s and ]s around the updates/builds in both lists.

  • Is there some way to get the current release? then we could change

Both should be addressed on prod via https://pagure.io/fedora-qa/blockerbugs/c/4955808512ffc7388ec5db993004d5bf6f609e9f?branch=releng_requests_prod . Does it work for you/did I get it right?

Frantisek, please create some local branch, e.g. feature/releng-commands and make it reflect the current patch in production, please. It'll help us see what the current code is, and I'll work on it once F38 is out to properly merge this to develop. Thanks.

Frantisek, please create some local branch, e.g. feature/releng-commands and make it reflect the current patch in production, please. It'll help us see what the current code is, and I'll work on it once F38 is out to properly merge this to develop. Thanks.

Yeah, you can take a look at either:
- mentioned commit (https://pagure.io/fedora-qa/blockerbugs/c/4955808512ffc7388ec5db993004d5bf6f609e9f?branch=releng_requests_prod )
- ansible buildconfig: https://pagure.io/fedora-infra/ansible/blob/main/f/roles/openshift-apps/blockerbugs/templates/buildconfig.yml#_20 (releng_requests_prod)

There is a branch that gets deployed (that as of now contains this PR and mentioned commit on top of it, with master as a base).

Feel free to ping me off-ticket if you have any questions/concerns, and let's keep the discussion related to this change, and not the deployment details.

So the branch already exists as releng_requests_prod. Ok. I just pushed a small fix into it.

Feel free to ping me off-ticket if you have any questions/concerns, and let's keep the discussion related to this change, and not the deployment details.

I actually wanted to have this documented in this very PR, because I'll not remember the details a month later when I can work on it :-)

Both should be addressed on prod via https://pagure.io/fedora-qa/blockerbugs/c/4955808512ffc7388ec5db993004d5bf6f609e9f?branch=releng_requests_prod . Does it work for you/did I get it right?

That looks good to me.

Thanks for working on this.

That looks good to me.

Thanks for working on this.

Was happy to help, it'll help us in the end but not having to worry that much that something is missing from the compose :D

Thanks for the PR, @kevin !

Finally had a chance to try this today for stable pushes.... and realized I messed up one thing. builds need to be , seperated.
so, can we change the space in that loop to a , ?

Also, there's a space missing on updates that have multiple builds...

this is wrong. it lists every blocker/FE-fixing build, even ones in updates that aren't queued for stable. It needs to only include updates where update.request == 'stable', just like the other existing FREEZE PUSH blocks.

Finally had a chance to try this today for stable pushes.... and realized I messed up one thing. builds need to be , seperated.
so, can we change the space in that loop to a , ?

this is wrong. it lists every blocker/FE-fixing build, even ones in updates that aren't queued for stable. It needs to only include updates where update.request == 'stable', just like the other existing FREEZE PUSH blocks.

Both should be addressed now (deployed) by https://pagure.io/fedora-qa/blockerbugs/c/111b4ade2bbd8f0d2ec3fd55f3cca8b010020e6e?branch=releng_requests_prod .

Does it work for you @kevin and @adamwill ?

yeah, current prod lgtm at least as far as I know.

Looks good to me too.

I started working on mainlining this and wanted to create a separate PR, but I've hit a roadblock. @kevin Please see #275 with the details, thanks.

I'm closing this in favor of #275, let's continue there, and I'll then create a fresh PR.

Pull-Request has been closed by kparal

a year ago
Metadata