#6703 Prep for Docs FAD - CI - High Priority
Closed: Fixed 6 years ago Opened 6 years ago by bex.

The Fedora Docs FAD will start on 26 February. A portion of the FAD is focused on enabling automatic building for docs.fedoraproject.org.

Please let me know the status of the following needs:

1) A job that is executed based on PRs and new commits from a series of repos, for example every repo listed at pagure.io/fedora-docs
2) A build environment where that job can run that has access to ruby gems that are not packaged
3) A temporary hosting platform for building scratch builds of docs PRs and serving them (stretch goal)

Is there anyone in particular who can be a point of contact for questions related to this during the FAD (26 Feb - 2 March)?

CC: @bstinson @jperrin @mattdm


On point 2: I think everything we need is packaged for Rawhide and will be in F28. https://src.fedoraproject.org/rpms/rubygem-ascii_binder

Hey bex.

So, there are a lot of ways to do items 1) and 3). Have you decided on something? Or thats going to be setup at the docs FAD, or it needs to be setup before the docs FAD?

Some ideas:

  • We could use openshift for this perhaps. I am not sure if we have worked out how to listen for fedmsgs inside openshift yet, so that might be a issue. Openshift itself can look at commits, but I think we would need fedmsg for PR's. Openshift could then do a build and publish. We could point docs there, or we could still sync from there to the static sites on the proxies. Concerns here are fedmsg and it's currently difficult/poorly documented how to create the openshift templates we use to deploy apps.

  • We could try and get our loopabull setup working. This would then listen for fedmsgs (PR or commit) and run an ansible playbook that could check things out, apply, build and push to proxies. Concern here is that we don't have this working yet and may run into snags with the setup.

  • For 3) we could just spin up a cloud instance and have it listen/build/serve things? Would still need some scripting around fedmsg, etc to get it working.

  • Something with the CentOS-ci? I think we already have some things working with it and pagure, could just have it listen/build/publish and we could pull from there to our static proxies content.

  • Something else?

Anyhow, let us know if you need this working before the fad or just work on it during and if there's a way that sounds more appealing to you than any others and we will try and do the best we can to accommodate you.

The FAD is aimed at actual writing, so as much as we can have in place before would be awesome.

@kevin this needs to be working before the FAD as I will be finalizing the tooling jobs during the FAD. The FAD starts on Monday.

Something else?

If we want to use Openshift instead of using fedmsg we could use pagure's webhook settings. I think Openshift builds can be triggered by webhooks.

I am not aware of pagure having webhooks for commits, just PRs, @cverna

pagure's webhook is sending the same messages as the fedmsg so all the fedmsg topics are available via the webhook.

In the case of commit I think https://fedora-fedmsg.readthedocs.io/en/latest/topics.html#pagure-git-receive would work.

cc @pingou in case I am wrong.

I just double checked and it is possible to trigger the webhook for every commit, however there is a catch you need to have the fedmsg hook enabled in your project.

Adding some details gather on IRC with @bex :

  • build trigger on commit for specific branch will rebuild docs.fp.o
  • build trigger on PR (commit on non specific branch) will be used for review, an independant url needs to be provided for each PR. ( URL and build output can be used in the PR comments to +1 the PR)

We can add "enable the hook" as part of our instructions.

So here's where we are right now:

We have a tenant in apps.ci.centos.org that builds the entire docs-fp-o structure based on a pagure webhook: http://docs-ci-fedora-docs.apps.ci.centos.org/ <- this is powered by @cverna's pagure-2-openshift tool, and Jenkins pipelines.

The working plan is to point all of the repos in the fedora-docs group at this webhook and the entire site will be regenerated at that URL when a commit is made on any branch in those repos.

We also have a generic s2i builder that can either rebuild the entire docs-fp-o site (see above), or, if given a docs sub-repo (e.g. the infra-guide) and a pull request, can build the individual site per-PR. There is much left to do here to create the services and deployments to serve these, but we are exploring ways to make this happen, and hope to have this done by the weekend. This is likely to take the form of a separate build pipeline specifically for the PR management.

@bstinson @cverna this sounds fantastic. Let me know how I can work with you starting on Monday EU time to get the build scripts adapted for what is needed. Huge props!

We have the start of per-PR sites as well. On Monday we'll get @bex access to Jenkins so he can see the pipelines and start on the triggers.

There were 2 projects in the fedora-docs groups with pull-requests. Here's what those URLs look like:
http://install-guide-pr1-fedora-docs.apps.ci.centos.org/index.html

http://system-administrators-guide-pr10-fedora-docs.apps.ci.centos.org/index.html

For transparency's sake, all of this was deployed from a directory in my fork:
https://pagure.io/fork/bstinson/fedora-docs/docs-fp-o/blob/add-dockerfile/f/openshift

README and Pull-request to the base repo will come soon as well.

So, the docs fad is over now? Shall we close this and open a new ticket about using this for production docs sites (as soon as we are ready/wanting to do that?)

This is still not in production, however I am ok with tracking this in a new ticket. I am in another FAD this week, but will be able to focus again next week. Thank you.

Cool. File that when ready. We should probibly meet up on irc and discuss how we want things to work, then file the ticket to do that work.

Metadata Update from @kevin:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

6 years ago

Login to comment on this ticket.

Metadata