[openstack-dev] [requirements][stable] EOL tags and upper-constraints.txt in tox.ini
prometheanfire at gentoo.org
Wed Sep 20 18:29:38 UTC 2017
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.
Matthew Thode (prometheanfire)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the OpenStack-dev