On Sat, Dec 17, 2016, at 03:59 PM, Robert Mayr wrote:
2016-12-17 15:02 GMT+01:00 Brian Exelbierd <bex@pobox.com>:


On Sat, Dec 17, 2016, at 02:59 PM, Robert Mayr wrote:
2016-12-16 20:59 GMT+01:00 Brian Exelbierd <bex@pobox.com>:
Hey,

Do we have a model/example for automatic site publication after a pagure
push?  I need it for something I am working on.

I'd like to see if I can set up the new budget.fp.o to publish on
commit.  The publication will require a job to be run to generate the
html (or error out if the commit is bad).

Thank you.

regards,

bex
_______________________________________________
websites mailing list -- websites@lists.fedoraproject.org
To unsubscribe send an email to websites-leave@lists.fedoraproject.org


Not sure if I understand what you want to do, but a push to pagure will not result as an immediate publication.
We build the websites hourly with a syncstatic script, that means if you push something to the repo it will be published more or less within the next 60-90 minutes.


I am trying to do this:

1. Allow several committers to a rep

No, you cannot add other people to the websites repo, because they would have write access to all websites. You could fork the repo and add other committers in your fork.
Once you are happy with the changes you could make a PR to the websites repo and merge it by yourself.

this would be for the budget website which I need to auto-generate from the budget pagure repo.

 

2. Ideally have CI/CD that would block PRs that fail tests - but I don't think we have an infrastructure this advanced yet
    Therefore, I think I need to block on publication if a commit is bad.

No, we do not have this kind of testing actually. We have it for the Flock registration app. Would be nice to have this kind of testing in a future release of pagure though. The only thing pagure will tell you, is if it can be merged directly, or if it need a merge commit.
Yes, you need to block it and cancel a bad PR manually.

There was a mention of CI functionality for pagure in other threads and the fact that we have jenkins server somewhere.

regards,

bex