Re: Finished a prototype of GSoC project: Implement a new doc toolchain

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Pierre,

Thank you very much!


So as far as I know, currently, you are using web-hooks to do sync between
pagure and github.
Did you consider using the underlying requests repo of the project?

Yes, I also think it is the best way to track PRs. GitHub PRs are equivalents of Pagure requests. And we can include more metadata in requests. 

In other words, for each project in pagure, there are 4 git repos:
- the code of the project (the repo people clone/fork/work on)
- the doc repo, for storing the project's documentation if that project wishes
 to
- the tickets repo of the project (a JSON representation of every issue ever
 opened against the project)
- the request repo of the project (a JSON representation of every pull-request
 and discussion about it opened against the project)

All links are available at the bottom of the project's overview page.
Note: tickets and requests repos are private (only people with commit to the
main repo can clone them)

Really helpful, thanks! It is more flexible than using API / web hooks.

If we run a pagure instance locally, we just directly modify the ticket repo, commit the changes and all set ;) Love it!


So when using the requests repo, upon receiving a notification from github, you
could create/update the appropriate JSON blob representing the pull-request and
push it to the requests repo.

We keep the code repo synced using a same workflow (pull from github to get the changes, then push to pagure) now. I think it will also work well for ticket repo.

From their pagure should update its database via a git hook to reflect the
new/update the PR in its UI.

Note: while interesting this is a part of the code that has been completely
tested yet, so we might run into a few bugs (in this case I guess we would run
into a few settings not being loaded correctly, nothing too problematic
normally).

Note2: I wonder if the PR model in Pagure could not be reworked so that it
defines the address of the repo from which to pull the changes, rather than
pointing to a pagure's project.
This way, we could open a PR on pagure from a repo hosted elsewhere.

If we have this feature, that'll be awesome! The major problem of using requests now is about creating requests. Because we have to create a pagure project for each user who open a PR on github (so pagure can pull the changes from those projects). Also, we need to create an account for each user. That’ll be difficult to manage. If we can pull changes directly from github, then all we need is a link :)

We are now implementing a two-way sync between pagure and github (mainly comments, so users and staff can discuss and don’t need to leave their own platform). Two-way syncs are a little bit tricky, though ;) I think we may encounter some problems when dealing with high frequency changes.


So many ideas :)


Pierre
_______________________________________________
CentOS-docs mailing list
CentOS-docs@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos-docs

Best regards,
Lei
_______________________________________________
CentOS-docs mailing list
CentOS-docs@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos-docs

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Users]     [CentOS Virtualization]     [Linux Media]     [Asterisk]     [Netdev]     [X.org]     [Xfree86]     [Linux USB]     [Project Hail Cloud Computing]

  Powered by Linux