7 Commits

Author SHA1 Message Date
Előd Illés
2b8ee3aaec Fix upper-constraints redirect for new release naming
The new release identification / naming schema [1] (like:
2023.1 Antelope) broke the redirection rules for branch specific upper
constraint files as the stable branch names are from now on based on
the new release identification (like: stable/2023.1).

This patch fixes the redirections by introducing the release ID field
to series status, to translate a release name to 'stable/<release-id>'
where this ID exists.

[1] https://governance.openstack.org/tc/reference/release-naming.html

Change-Id: Iab885d4e36f64903b323e16c74d8315c759584de
2023-01-14 10:29:27 +01:00
zhaoleilc
46e30e8196 Correct a typo of an annotation
This patch changes 'begining' to 'beginning'
in an annotation of the _redirections.py

Change-Id: Ic29e3e924b1f59fb44f7fd64d9fbc960948b72ce
2020-07-23 14:26:21 +08:00
Tim Burke
e392f0bd48 Redirects to master should always be temporary
We *know* that requirements will have a stable/train branch soon; make
sure clients don't go caching the redirect to master.

Change-Id: I8507d86e4f553b698163be61665267d42e033d91
Related-Change: Ia2e8c46c27ac97217576afdd1677efba4b99fc37
2019-10-03 15:10:33 -07:00
Tony Breeds
5801fbdc77 Switch constraints files over to the new opendev infrastructure
Currently constraint redirectiones that point to EOL releases don't work
as expected due to gitea needed to differentiate between tags and
branches.  Rather than fix, and rely on multiple redirects lets just
craft 301's that point to the correct gitea url.

This means we now need to know when a target is a branch or tag but
that's pretty simple to intuit given our deliverable structure.

Change-Id: Ife030f8ee7b5d204b054f99e920a675f7d92da69
2019-05-22 14:33:37 +10:00
Tim Burke
a8d377c96d Use temporary redirects for future series
Per [1],

> [Permanent redirections] are meant to last forever. They imply that
> the original URL should not be used anymore and that the new one is
> preferred. Search engine robots trigger an update of the associated
> URL for the resource in their indexes.

That doesn't seem like a good idea when we *know* that the redirect
location is going to change, and on a reasonably short time scale. Use
302 instead; 303 or 307 would probably work as well, but 302 should have
very broad client support.

[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Redirections

Change-Id: Ia2e8c46c27ac97217576afdd1677efba4b99fc37
2019-03-25 22:54:11 -07:00
Tony Breeds
59c8c13058 Add 'Future' series names to the redirections
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
2019-03-16 07:55:05 +11:00
Tony Breeds
752ce5a491 Generate the constraints redirections from the deliverable data
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
2019-02-28 12:50:37 +11:00