Skip to content

pkg_in_pipe: move the plane cards of the builds of a tag to a given state - #840

Open
glehmann wants to merge 1 commit into
gln/json-report-output-onkpfrom
gln/sync-plane-cards-mktk
Open

pkg_in_pipe: move the plane cards of the builds of a tag to a given state#840
glehmann wants to merge 1 commit into
gln/json-report-output-onkpfrom
gln/sync-plane-cards-mktk

Conversation

@glehmann

@glehmann glehmann commented Aug 26, 2026

Copy link
Copy Markdown
Member

Add move_cards_to_state.py, which keeps the plane cards of the XCPNG
project in sync with the progress of the builds: the cards linked to
the builds of a given koji tag are moved to a given state, and never
backwards.

Signed-off-by: Gaëtan Lehmann gaetan.lehmann@vates.tech

This PR is part of a tree containing 4 PRs:

  1. master
  2. pkg_in_pipe: keep PRs merged by rebase or squash #838master
  3. pkg_in_pipe: write a machine readable version of the report #839pkg_in_pipe: keep PRs merged by rebase or squash #838
  4. "pkg_in_pipe: move the plane cards of the builds of a tag to a given state" (this PR) → pkg_in_pipe: write a machine readable version of the report #839
  5. pkg_in_pipe: generate a draft of the release post from the report #841pkg_in_pipe: write a machine readable version of the report #839

…tate

Add move_cards_to_state.py, which keeps the plane cards of the XCPNG
project in sync with the progress of the builds: the cards linked to
the builds of a given koji tag are moved to a given state, and never
backwards.

Signed-off-by: Gaëtan Lehmann <gaetan.lehmann@vates.tech>

@gduperrey gduperrey left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It bothers me a bit that the cards are being moved via a script based on the build location.

I’m worried we might start moving them just to keep things in sync, without verifying them first, which could result in them being incomplete.

@gduperrey
gduperrey requested a review from a team August 31, 2026 15:11

@rzr rzr left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change is welcome but prone to mistakes, I saw some cards with open PRs that were marked released while they should have been not touched. I would prompt user to list or confirm each stage change

@stormi

stormi commented Aug 31, 2026

Copy link
Copy Markdown
Member

I think a motivation is missing to this PR, as well as a description of the process update. It's already possible to bulk-move cards via the UI, and as others pointed out, moving states is supposed to come with checking that the conditions are met.

The question is whether updating the cards status is a formality that needs to be automated, or the occasion for the release team to check that everything is in order.

In particular, I'm against moving to "released" automatically without seeing any description of the new process, because that's currently when we check one last time that no documentation update is missing (though, at this stage, is rather late), and that we contact users in tickets, forum or github to let them know about a specific fix or feature they were waiting for.

So, to consider this automation, we need to understand what the release process looks like with this tool.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants