This makes sphinx-build use the number of cores available to make the
docs build parallel. On my 16 core system, this cut the time by ~50%. We
don't have as many cores available in the gate, but it should provide a
slight improvement in overall job time.
Change-Id: I7ad4d87a3dba10475a0fcf797a9aa2d4b1ad0eb5
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
In releases.o.o we display signature links for all deliverables,
if the series is > Ocata or independent. Since some "independent"
deliverables predate the signature generation tooling, that results
in a number of "independent" deliverables displaying broken signature
links, which makes us look bad.
This adds a flag (skipped-sig) that can be set for independent
deliverables that did not have any signature generated (pre-Ocata), and
skips the signature link display if the flag is set.
As a practical example, this fixes broken links for PBR<2. Tony signed
up to automatically generate the others.
Change-Id: I44a49e3f08010a85c64673d2292528139eabcc99
This updates our sphinx extension to show abandoned deliverables
as EOL, in a separate section at the bottom of the independent
deliverables page. It adds an 'EOL' mention to such deliverables
on team pages.
Change-Id: I56b9fbad9314c523e2f18765371746d21a71ed88
We have been filtering whether to include pgp links for deliverables if
the series was >= 'O', which resulted in filtering out any independent
deliverables.
This updates the check to account for independent deliverables. It also
makes the table format consistent for pre- and post-Ocata, just leaving
the column blank for series where we did not generate signatures.
Change-Id: I0c9f97cb12a429d2e54d94df2b3e110156278bc1
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
Our docs job has a lot of output that is not generally very useful.
Rather than bloating our log files, this switches some log calls over to
debug level so they are only emitted if needed.
Change-Id: Id0440ef506d0bc896d6dd4ba30473f430a6606dd
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
We want these tags in git for developers and those working directly with
the source code, but we do not want to have these listed on the releases
site. Consumers of the site are just looking for actual official
releases they can use, so we should avoid confusion by not including
these "internal" tags.
Change-Id: I6a3fcc11efed6254ea6fb95579eafe5288508661
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
Adding liaisons to deliverables where there is a liasion listed here:
https://wiki.openstack.org/wiki/CrossProjectLiaisons#Release_management
Also creates a data dir to put the non deliverable files that were in the
deliverables dir elsewhere and updates filepaths to reflect the change.
Story: 2005702
Task: 31024
Change-Id: Idc5f4b29dd375465b21d678fa8503cbd8d6d3eb6
With a large number of deliverables and different deliverable types, the
documentation output for a release series can get very long and it's not
always obvious that there are different groups of types if you scroll
all the way down.
This updates our deliverable extension to include a table of contents at
the top of the output to add convenient links to the different groups of
deliverables.
Change-Id: I3c55057320661f7167d44138941a07fd38c3c81f
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
In Ib5d35169e68cd92b666a35705d8e36942bd28b89 (Use a template to generate
the 'whereto' testing data) I did the simple copy'n'paste instead of
factoring the common code into a helper function.
Fix that
Change-Id: I3f0b93dd57db4811ed5c04a5a01a7ecca7ff539c
Once we have the nest series in series_status.yaml we can add
redirections for those constraints too. This allows us, should we want
to, to have branches refer to the series by name, instead of 'master'.
Change-Id: I0035190d11bf0c0bb43119fde18b5dc22d2cc1a0
As we add more branches and tags we don't want to manually add tests for
them (and we'd need to or the docs build will fail with an 'Untested
Rule'.
Use the redirections data that we use to generate the htaccess file to
also generate the tests.
Also I removed the debug output as it it's assertion is incorrect we can
actually get the .htaccess file from the docs job \o/
Change-Id: Ib5d35169e68cd92b666a35705d8e36942bd28b89
Instead of statically listing the redirections move to a dynamic model.
We move the existing _extras/.htaccess to _templates/htaccess so we have
some control and safety of what goes in there. Connect 'build-finished'
from _exts.deliverables.py to trigger generating the redirects. Doing
so here avoids re-reading the data as deliverables.py ahas already done
that for us.
Change-Id: If6bd59fd478593a84ebcedc3a50af3720d620d3c
We have static URLs redirecting /constraints/upper/series to the
appropriate git interface. In the next change in this series we move to
a data-driven model so let's supply the data :)
Even though we have tag history that goes back to Folsom only import
Juno and later because that's when we first added constraints support
This means as the create and delete branches for requirements, like
other projects, we have a central source of truth (other than git) from
which to update the htaccess redirects.
I had update deliverables.py to account for the fact most of the
requirements branches don't have a release. This does make the table
look a little funny (as the earliest release is the series eol tag :()
but I'm not sure how we can do better there.
Change-Id: Ie8e60dc865ab301539c0bb085a52dd25f3f62edf
Remove the governance code in this repository and use the new
openstack_governance library instead.
Depends-On: https://review.openstack.org/614605
Change-Id: Ia7ffff3945462f4b568b55287dfdf45fe73a35d9
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
We had sphinx extensions in multiple locations. This centralized them
under the doc/source tree.
Change-Id: Ieda73fb4b51ed78409423c41eaddacda199abddc
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
