To clarify, are those the APIs you want? I can prioritize them, when working on implementing the remaining API endpoint wrappers.

• Who am I? https://pagure.io/api/0/#heading-extras-api_whoami (DONE)
• Project info: https://pagure.io/api/0/#heading-projects-api_project (DONE)
• User info: https://pagure.io/api/0/#heading-users-api_view_user (DONE)
• PR info: https://pagure.io/api/0/#heading-pull_requests-api_pull_request_view (DONE)
• post PR comment: https://pagure.io/api/0/#heading-pull_requests-api_pull_request_add_comment (DONE)
• commit flags: https://pagure.io/api/0/#heading-projects-api_commit_flags (DONE)

As you mentioned, I see no (publicly documented) APIs for getting comments of a PR, or to view its flags (though there probably is a way).

• comment awards: what's this?

• issues closed by a PR: not sure it's possible to "formally" link pagure issues and pull requests in this way

• commit info: not sure what you want to query here. if you already now the commit hash then why do you need to query pagure for it?

• commit comment: if pagure doesn't support it, then there's nothing an API wrapper can do here, is there?
• PR awards: what's this?
• adding webhooks to projects: this might be available via "Update project options", though it's not documented how to do this: https://pagure.io/api/0/#heading-projects-api_modify_project_options

Yep. The first list are "required" for the set of actions provided today.

I can prioritize them, when working on implementing the remaining API endpoint wrappers.

I can contribute as well, but I'd like to know what the future looks like before doing so (hence #1)

comment awards: what's this?
PR awards: what's this?

GitHub and GItLab allow attaching emoji to comments and PRs. GitLab calls them "awards", so that's what the abstraction calls them (since it was first). We use it as a "this comment was handled" marker. One of the design principles of the stack is that the hosting service holds all state which means the tool itself doesn't need a database or some other store that would require synchronization with the service. We could instead add an HTML comment to it to indicate "handled" if the token in use has permission to edit any comment on the project.

issues closed by a PR: not sure it's possible to "formally" link pagure issues and pull requests in this way

OK. That can be just Ok(Vec::new()) then.

if you already now the commit hash then why do you need to query pagure for it?

The refname for it on the server (branch or tag usually) and the "pipeline" associated with it (if any). "Flags" is useful, but if flags can supercede each other, the combind status of all "latest" flags as far as the service is concerned is very useful.

commit comment: if pagure doesn't support it, then there's nothing an API wrapper can do here, is there?

True. Looking at it, it's a workflow process unlikely to be used on Pagure anyways (LFS or git-annex handle the workflow item that ends up doing this bit).

adding webhooks to projects

I think this is ignorable for Pagure; the fedbus configuration is a better place to change what events end up somewhere. We use it on our instance to have the robot automatically subscribe itself to every project.

comment awards: what's this?

Pagure calls them "reactions", but I don't see an API for this. You can see this in the UI by clicking on the "heart" and you'll see the options for reactions.

Filed RFE as https://pagure.io/pagure/issue/4888

issues closed by a PR: not sure it's possible to "formally" link pagure issues and pull requests in this way

It's currently not possible via API, but Pagure will link them if the commit and/or initial comment has Fixes <issue number/issue URL>. When a PR is merged, it closes them automatically in this case.

Filed RFE as https://pagure.io/pagure/issue/4890

adding webhooks to projects: this might be available via "Update project options", though it's not documented how to do this: https://pagure.io/api/0/#heading-projects-api_modify_project_options

I don't think this is a thing right now.

Filed RFE as https://pagure.io/pagure/issue/4889

Thanks for the issues over there

Pagure calls them "reactions", but I don't see an API for this. You can see this in the UI by clicking on the "heart" and you'll see the options for reactions.

Ah. I guess something is up; that button only render on new comments after refreshing the page for me, so I missed them.

I've added and pushed implementations for the missing "essential" APIs. All "non-destructive" actions are tested against pagure.io and should work.

If I'm not missing anything, this leaves the following "nice-to-have" things:

• comment reactions: the API for querying PR information returns them (attached to the respective comments), but there's no API I see to set them (RFE filed for pagure)
• issues closed by a PR: RFE filed for pagure
• commit info: still not sure what information you need here
• post commit comment: no support in pagure
• PR awards / reactions: there are no reactions on the "initial comment" of a PR, so I don't think pagure supports this
• configuring webhooks for projects: RFE filed for pagure

Coming back to this finally :) . I have initial (untested) support locally. My TODO items in the code are:

• knowing what the domain we're communicating with is (used to generate email-for-users when needed)
• group membership lists (though this is more a "need to look into what I need yet" thing)
• commit information (the refname, if any, for the commit in the repo, CI "pipeline" information or some handle to the set of latest CI information for the commit)
• adding a reaction to an PR comment
• issues closed by a PR
• adding issue labels

I'll track down what the status from the Pagure side is next.