On 10/26/2017 08:56 AM, Brian Exelbierd wrote:

On Thu, Oct 26, 2017, at 02:52 PM, Eduard Lucena wrote:

...

Hi team,

I was talking with Matthew Miller and we believe that we should change
the way our publishing process stages.  Specifically, we should
have the
new CI job that does publishing push updates to both docs.stg.fp.o and
docs.fp.o at the same time.

This sounds good!

Fedora infrastructure republishes docs.stg.fp.o approximately every 5
minutes and they republish docs.fp.o once per hour.  By pushing to
both
we are creating a situation where accepted changes go live faster.  In
general we have time to catch any staging errors with a new
publish, and
in the case where we miss it, the site is republished an hour later
anyway.

Wow, that's fast! If we can push this hourly to prod, we will be doing great!

Infrastructure implemented this for us a couple of months ago.  We can do this today, we just have a manual build process.  docs.stg.fp.o is updated with a new design and will probably go live to docs.fp.o soon.

Take a look at provide some feedback :)

I am +1. Anywhere we can automate where it makes sense sounds logical to me. I would imagine some amount of mistakes are probably fixed shortly after publication anyways, which fits this model.

On Thu, Oct 26, 2017, at 07:42 PM, Zach Oglesby wrote:

On Thu, 2017-10-26 at 10:52 +0200, Brian Exelbierd wrote:

...

Hi,

I was talking with Matthew Miller and we believe that we should change the way our publishing process stages. Specifically, we should have the new CI job that does publishing push updates to both docs.stg.fp.o and docs.fp.o at the same time.

Fedora infrastructure republishes docs.stg.fp.o approximately every 5 minutes and they republish docs.fp.o once per hour. By pushing to both we are creating a situation where accepted changes go live faster. In general we have time to catch any staging errors with a new publish, and in the case where we miss it, the site is republished an hour later anyway.

What do you all think?

regards,

bex

Using CI to push out changes was a part of the plan that we came up with at the FAD and I think it is important. The only reason that I have not pushed for it yet was that things are still in flux. Bex, as the person with the best understanding of the code and what major changes are still pending I think you are in the best position to know when it makes sense to implement this. My worry so far has been pushing fundamental changes to the site that break something, if you think we are past that point then I am a +1 for sure.

I think we are ready to begin testing this.

The current builder is not very intelligent so we need to think through some tests that should gate us. In particular, we are publishing some repos provided by groups other than the docs team, so we need a logic that can recover if they have a challenge. I have ideas here, but no significant implementation time.

In an ideal world, someone who is interested in CI and wants to do the implementation will step forward. I can provide information about the build process so they don't have to learn all the tools from scratch and access to the people who can help us enable CentOS CI.

If no one comes forward (or there is a delay), I will make incremental progress as soon as possible on getting docs.stg.fp.o to rebuild and still do manual pushes to prod. This will allow us to find the "gotchas" over time, as opposed to being more methodical.

regards,

bex