On Wed, Jul 22, 2020 at 02:19:59PM +0200, Mark Wielaard wrote: > Hi Tom, > > On Tue, 2020-07-21 at 13:53 +0100, Tom Hughes via devel wrote: > > On 21/07/2020 13:12, Mark Wielaard wrote: > > > > I normally just edit .git/config and add to the origin remote > > > > an extra fetch: > > > > > > > > fetch = +refs/pull/*/head:refs/remotes/origin/pull/* > > > > > > > > then after fetching you can merge origin/pull/NNN. > > > > > > But this is very helpful! Thanks. > > > > > > So with that I can easily do checks, adjustments, create my own > > > commits, do cherry-picks or merges, etc. But how does it interact with > > > the website? How do I sent comments? I see it comes with a mini-CI koji > > > run, does it add a tag to the commit as tested when it succeeds/fails? > > > How do I indicate which changes I made/pushed or which changes I would > > > like the submitter to make? How do I discard a pull if I determine it > > > isn't useful? etc. > > > > You use the web site as far as I know. > > > > Unlike github it doesn't even notice when you push a merge so > > you still have to close the PR on the web site as well. > > > > > And if I wish to create a pagure pull request myself, do I simply push > > > to pull/NNN? How do I determine which NNN to use? > > > > Well you push to a branch on your fork but then you have to > > use the web site to open the PR I think. > > > > I mean there is a pagure API through which you can likely do > > all these things but AFAIK there is no CLI interface for it so > > you have to hit it with curl or something ;-) > > I found libpagure, which makes it possible to write some command line > tooling. The library is a little clunky imho, but that might be because > my python is a little rusty. But I was able to comment on the pull > request and actually merge it. Although I wish I hadn't because it > doesn't do a rebase first. But combined with the .git/config trick to > add: > > fetch = +refs/pull/*/head:refs/remotes/origin/pull/* > > libpagure has the potential to create a useful workflow. For others > that want to try, you'll initialize through something like: > > >>> from libpagure import Pagure > >>> pg = Pagure(pagure_token="xxx",instance_url=" > https://src.fedoraproject.org/",pagure_repository="rpms/valgrind";) > >>> pg.comment_request(1, "Trying out libpagure commenting. This > request looks reasonable.") > > As you say, the web api is even more resourceful and we can integrate > some of those requests into the library: https://pagure.io/api/ > > The only thing that is not very nice are those pagure_tokens. I was > hoping you could get a temporary one through simple fedora kerberos > authentication. But the only way to create one seems to be through a > webbrowser: https://src.fedoraproject.org/settings#nav-api-tab > You can create one that is valid for 2 years, which is helpful, but > doesn't feel very secure. How do people manage those tokens? > > And I really would like to see a mail backend (maybe simply accepting > gpg signed emails) so you don't have to be online just to deal with > these kind of pull requests. Dan Berrange is writing a thing called bichon. It ony works with gitlab at the moment, but AIUI he'll accept patches to support other "*hubs". https://gitlab.com/bichon-project/bichon Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
