On 17-09-20 13:43:51, Tony Breeds wrote: > On Wed, Sep 20, 2017 at 01:08:45PM -0400, Doug Hellmann wrote: > > Excerpts from Jeremy Stanley's message of 2017-09-20 13:36:38 +0000: > > > On 2017-09-20 08:41:14 -0400 (-0400), Doug Hellmann wrote: > > > [...] > > > > Is there any reason not to use the published files for all regular > > > > builds, instead of having tox.ini point to a git URL? Maybe only for > > > > regular builds off of stable branches? > > > > > > I'm not sure what you mean by "regular builds" but the plan as I > > > > s/regular/non-CI/ > > > > > understood it was to switch from git.o.o URLs to releases.o.o URLs > > > in the tox.ini files in all branches of projects already consuming > > > constraints files that way. > > > > > > As early as now (if we already had the publication job in place) we > > > could update them all in master branches to retrieve something like > > > https://releases.openstack.org/constraints/queens-upper-constraints.txt > > > and then once stable/queens is branched in all repos (including the > > > requirements repo), switch the job to begin publishing to a URL for > > > rocky and push tox.ini updates to master branches switching the URL > > > to that as early in the cycle as possible. Alternatively, we could > > > publish master and queens copies (identical initially) and expect > > > the master branch tox.ini files to refer to master but then switch > > > them to queens on the stable/queens branch during RC. It just comes > > > down to which the stable/requirements/release teams think makes the > > > most sense from a procedural perspective. > > > > We should think through which of those approaches is going to result in > > the least amount of synchronization. We do have a window in which to > > make changes in a given branch for consuming projects, but making the > > relevant changes in the requirements repository seems like it could be > > error prone, especially because we try to branch it after the other > > repositories. > > The solution I thought we decide on at the PTG is: > * Add a post job to all branches that publish a constraints/$series.txt > to $server (I don't mind if it's releases.o.o or tarballs.o.o). > * On the master branch we publish both master.txt and $series.txt > (currently queens.txt) when we fork rocky from master we update the > publish job to publish master and rocky.txt. As Doug points out > there is a timing race here but it;s much smaller than the one we > have now. > * We update the projects to use the static (non-git) URL for the > constraints files. > * We update the release tools to generate the new style URL. > > Optionally, and this requires discussion, we use a custom tox_install.sh > to extract the branch from .gitreview and generate the URL which would > remove the need for the last step. There are clearly pros and cons to > that so I'm not advocating for it now. > > Those constraints files would never be removed but they'd stop getting > updated when we EOL the requirements branch. > > How does that sound? > > Yours Tony.
That's correct, I haven't had time this week to create the jobs quite yet, but hope to do so either this weekend or next week. It's #3 in our list of items to generate tasks/bugs from. https://etherpad.openstack.org/p/queens-PTG-requirements -- Matthew Thode (prometheanfire)
signature.asc
Description: PGP signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
