pagure

#4002 Pull request detail API endpoint should return a non-cached merge_status
Opened by fbo. Modified

Open
Close Issue

As an API user to act as a CI gating system for Pagure I need to be able to rely on a reliable merge status information.

After some experimentation, with minimal score to merge set to 1 for a project the cached_merge_status state remains 'unknown' until the minimal score to merge is reached.
That's not expected, I would have expected 'SCORE' as status or at least an indication about the score not reached.

I was able to mitigate to this behaviour but I figured out that when someone add its :thumbsup: the status still remains (via the API) 'unknown' until someone access the PR page via the UI. Then if I call again the API endpoint I got a status CONFLICT|MERGE|FFORWARD.

I guess the pv/pull-request/merge private endpoint manage to refresh the status but as API I can't use it :(

Could it be possible to trigger a cache_merge_status in case of :thumbsup: or :thumbsdown: in a comment ? (Maybe I should open a separate issue ? as it seems more simple to fix only that than replacing cached_merge_status by a fully reliable merge_status).

The last sentences contained a typo. It is instead:
Could it be possible to trigger an update of the cache_merge_status in case of 👍 or 👎 in a comment ?

@fbo My understanding is that pushing a comment with :thumbsup: or :thumbsdown: is enough to make that update.

@ngompa I just re-tried and no the cache_merge_status is not updated.

Please follow the process below to see it:
1/ Access this https://pagure.io/api/0/test-zuul/pull-request/28 and as you can the status is "unknown" also look at the comment[0] (thumbsup).
2/ Access https://pagure.io/test-zuul/pull-request/28 it will update the cache_merge_status under the hood.
3/ Finally go back to https://pagure.io/api/0/test-zuul/pull-request/28 then you get the updated cache_merge_status (MERGE).

This project have a minimal score to merge at 1.

For my use case I'll be happy with a refresh only when a thumbsup/down are set. But ideally the merge_status should be accurate at any time when you use the API.

I believe the situation will be better once #4016 is in and deployed :)

I see the fix include a rebase button on the UI (I like it !, for instance on Gerrit I use it a lot, and I think it missed from Github) Nice that Pagure will have one :) Also but I'm not sure do you mean the change will make the cached_merge_status more accurate ?

https://pagure.io/pagure/pull-request/4121

@fbo did #4121 fix this ticket and I just missed closing it or is the issue still present?

No. That was not the same issue. Here cached_merge_status remains unknown until someone access the web page of the PR. Automation tools that relies on json access like https://pagure.io/api/0/test-zuul/pull-request/xx won't get the right status until an human access the web page of the PR so that's problematic.

I've just check and the issue on the prod instance.
Edited by fbo
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.