Re: [openstack-dev] [docs] rethinking docs jobs in the gate
On 02/16/2015 04:36 PM, Doug Hellmann wrote:
> When we talked about this in the review of the governance change to set
> "tox -e docs" as part of the testing interface for a project, jeblair
> (and maybe others) pointed out that we didn't want projects running
> extra steps when their docs were built. So maybe we want to continue to
> use "tox -e venv -- python setup.py build_sphinx" for the real docs, and
> allow a "tox -e docs" job for the check queu for testing.
trove has XML docs and sphinx (AFAIK), so calling build_sphinx will not
do everything.
Let me work on a patch for trove now...
Andreas
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu,
Graham Norton, HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [docs] rethinking docs jobs in the gate
On 02/16/2015 10:38 AM, Christian Berendt wrote:
> On 02/16/2015 04:29 PM, Andreas Jaeger wrote:
>> For documentation projects we should discuss this separately as well,
>
> Is it possible to keep all environments like they are and to add a meta
> environment (called docs) calling the existing environments? This way we
> can reduce the number of jobs on the gates (entry point for the gates is
> the meta environment) but can keep the existing environments for local
> tests.
Why do you want them all in different venvs? Are there a lot of
instances where you only run one of them? And if so, is there a reason
not to do like we do with unit tests on projects and support a {posargs}
to select a subset.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [docs] rethinking docs jobs in the gate
On 02/16/2015 04:29 PM, Andreas Jaeger wrote: > For documentation projects we should discuss this separately as well, Is it possible to keep all environments like they are and to add a meta environment (called docs) calling the existing environments? This way we can reduce the number of jobs on the gates (entry point for the gates is the meta environment) but can keep the existing environments for local tests. Christian. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [docs] rethinking docs jobs in the gate
On Mon, Feb 16, 2015, at 10:05 AM, Sean Dague wrote: > I've noticed a proliferation of docs jobs on projects in the gate now - > https://review.openstack.org/#/c/154737/ > > gate-trove-tox-checknicenessSUCCESS in 2m 34s > gate-trove-tox-checksyntax SUCCESS in 2m 51s > gate-trove-tox-checkdeletions SUCCESS in 2m 11s > gate-trove-tox-doc-publish-checkbuild SUCCESS in 4m 46s > > in addition to the base: > > gate-trove-docs SUCCESS in 2m 31s > > I'm not sure I understand why these docs jobs are separate, and not all > part of gate-trove-docs. > > > It seems like it would be good if 'tox -e docs' was the docs test entry > point, and if a project wanted to test for these various checks in the > docs those would be changed in tox.ini for the project for that docs > target. > > It also means you don't have to build and maintain multiple local venvs, > and would substantially reduce test nodes used in upstream testing. When we talked about this in the review of the governance change to set "tox -e docs" as part of the testing interface for a project, jeblair (and maybe others) pointed out that we didn't want projects running extra steps when their docs were built. So maybe we want to continue to use "tox -e venv -- python setup.py build_sphinx" for the real docs, and allow a "tox -e docs" job for the check queu for testing. Doug > > -Sean > > -- > Sean Dague > http://dague.net > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [docs] rethinking docs jobs in the gate
On 02/16/2015 04:05 PM, Sean Dague wrote:
> I've noticed a proliferation of docs jobs on projects in the gate now -
> https://review.openstack.org/#/c/154737/
Trove is the only project using XML files and thus uses the
openstack-manuals setup for these.
>
> gate-trove-tox-checkniceness SUCCESS in 2m 34s
> gate-trove-tox-checksyntaxSUCCESS in 2m 51s
> gate-trove-tox-checkdeletions SUCCESS in 2m 11s
> gate-trove-tox-doc-publish-checkbuild SUCCESS in 4m 46s
>
> in addition to the base:
>
> gate-trove-docs SUCCESS in 2m 31s
>
> I'm not sure I understand why these docs jobs are separate, and not all
> part of gate-trove-docs.
It's easy to merge them for trove.
>
> It seems like it would be good if 'tox -e docs' was the docs test entry
> point, and if a project wanted to test for these various checks in the
> docs those would be changed in tox.ini for the project for that docs target.
Trove is the only python project doing it this way.
> It also means you don't have to build and maintain multiple local venvs,
> and would substantially reduce test nodes used in upstream testing.
For documentation projects we should discuss this separately as well,
Andreas
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu,
Graham Norton, HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
