On Thu, Oct 26, 2017, at 07:42 PM, Zach Oglesby wrote:
On Thu, 2017-10-26 at 10:52 +0200, Brian Exelbierd wrote:
> I was talking with Matthew Miller and we believe that we should
> the way our publishing process stages. Specifically, we should have
> new CI job that does publishing push updates to both docs.stg.fp.o
> 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
> 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,
> in the case where we miss it, the site is republished an hour later
> What do you all think?
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.