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

[glehmann]

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: write a machine readable version of the report #839 → master
3. pkg_in_pipe: log the progress, the cache usage and the source problems during the generation #849 → pkg_in_pipe: write a machine readable version of the report #839
4. "pkg_in_pipe: move the plane cards of the builds of a tag to a given state" (this PR) → pkg_in_pipe: log the progress, the cache usage and the source problems during the generation #849
5. pkg_in_pipe: generate a draft of the release post from the report #841 → pkg_in_pipe: log the progress, the cache usage and the source problems during the generation #849

[gduperrey]

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.

[rzr]

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]

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.

[rzr]

i dont think you want to commit this

add *.pyc to gitignore ;)

[rzr]

do we want to hardcode internal urls here ? I would prefer env vars like you are doing later with PLANE_TOKEN

[rzr]

nitpicking: I would name file with a plane- prefix