@pingou @psss @bookwar kindly asking for review

I tested the script and it seems to work on our staging pagure instance we have internally. I was not able to test loop-a-bull ...

I don't understand the implementation in detail but in general the proposed approach seems fine to me: Showing only one flag with either running or complete/error status is probably the best solution for now, until we get proper handling of pull requests versions/rebases.

@kevev @puiterwijk @smooge @pingou hi, would anybody have time to review this pls? We would like to show this feature on DevConf CZ. Thanks very much.

Let's add a default value to this variable so we're backward compatible

s/if/elif/

let's find a way to generate these, it shouldn't be a static and public string.

@pingou all issues addressed, politely asking for another round of review

We need to come up with a better way to generate the uid, this is still too weak :(

@pingou can you elaborate what is the problem, please? Is it that someone cannot fake easily the result or? Should I add more strings to the generation, so it is not just one value hashed? ... btw on downstream we just remove all old flags with "[citest]", is that something we do not want to do here?

The problem we were trying to solve with this was: https://pagure.io/fedora-ci/general/issue/1 (if we have just one result, no need to write which commit it relates to). Also with a rebase the reference to hash makes little sense.

@pingou updated to use seed_flag_ci_pr variable for hash calculation. Please take a look. ty!

Looks fine to me :)