#4466 show git hash in CI flags if flag.commit_stop is available
Closed 4 years ago by karsten. Opened 4 years ago by karsten.
karsten/pagure show_commit_hash_in_ci  into  master

@@ -612,7 +612,11 @@ 

                </div>

              </div>

              <small><div class="clearfix">

-                 <span>{{ flag.comment }}</span>

+ 		{%- if flag.commit_stop %}

+                   <span>{{ flag.comment }}  {{ flag.commit_stop }}</span>

+                 {% else %}

+                   <span>{{ flag.comment }}</span>

+                 {% endif -%}

                  <div title="{% if

                    flag.date_created == flag.date_updated -%}

                      Created at {% else -%} Updated at {% endif -%}

Some CI systems like Fedora CI don't return the commit hash in their comment section and this makes it unclear on which state of the git repository the CI test have been executed.
Ideally this should be added to the code of the CI system, but nobody I've asked seems to know which component returns "Fedora CI".
This solution will most likely show wrong hashes for older runs of Fedora CI, though

Signed-off-by: Karsten Hopp karsten@redhat.com

This solution will most likely show wrong hashes for older runs of Fedora CI, though

Which makes it loose its entire interest :( You're no longer able to know on which commit a run was against.

Ideally this should be added to the code of the CI system,

Big :thumbsup: on this, I don't think we want this in pagure itself.

I've checked datagrepper and a couple of pull requests. Fedora CI already sends the commit_stop with fedmsg and pagure shows it in for example
https://src.fedoraproject.org/api/0/rpms/mariadb/pull-request/11/
(The initial PR hash is unknown and 9cfb1fc004ce5b5c584ce1af12acecb42cc409a2 that is also mentioned is not in git due to a fast-forward rebase). Do we really need to mention 9cfb1fc when it is not available anymore due to a FF-rebase ?
Another question: https://src.fedoraproject.org/rpms/mariadb/pull-request/11 shows only one "Fedora CI" run although there should have been one 3 months ago.
I haven't found any other pull requests that show more than one "Fedora CI" in Flags, btw. If that's intentional, my comment about older Fedora CI runs is obsolete, anyway.

Sorry, I finally remembered what adds this flag on PR, it's a script in loopabull: https://pagure.io/Fedora-Infra/loopabull-tasks/blob/master/f/playbooks/roles/flag_ci_pr/files/flag_ci_pr.py

I haven't found any other pull requests that show more than one "Fedora CI" in Flags, btw. If that's intentional, my comment about older Fedora CI runs is obsolete, anyway.

Looking at the code, it is intentional, it generates a hash from the PR ID (+ a seed), so the flag should be unique per PR and there should always be only one

that info about loopabull helped a lot, thanks. upstream-fedora-pipeline got fixed and I've created a PR for loopabull.
I'll close this one

Pull-Request has been closed by karsten

4 years ago