Cycle-trailing deliverables are regular cycle-following deliverables,
using RCs or not not using RCs -- they just have a different deadline.
Rather than using a release model, those deadline variants are better
described using deliverable types, in much the same way 'library'
deliverables have a specific deadline too.
This simplifies the list of models significantly, and allows to have
proposer validation of trailing deliverables that use RCs or not use
RCs.
For compatibility in old branches, setting 'cycle-trailing' is still
supported, it will just overload the type to 'trailing' if specified.
Change-Id: Ifce88ef3e5dd406f45f25214699f16e736ad5377
This adds a new std-with-versions branch type. This is used to control
validation logic when branching to allow the Ironic team to create
intermediary stable branches based on major.minor version numbers in
addition to our normal expected stable/$series branches.
https://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/new-release-model.html
Change-Id: Ic482c77a2c177162ffe37643a455ac1724a658b3
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
Introduce an 'abandoned' release model for cycle-independent
deliverables. It should only be applied to deliverables in the
_independent directory. No new release should be accepted for
deliverables with this release-model.
Change-Id: I65c163888c37f7a7f77273abf3ca0633923a0fe2
Some "other" deliverables like tempest and patrole never
create stable branches. This allows to clearly mark such
deliverables and add a corner case in validation tests.
Change-Id: I2f6414d0f71baad58335702743f2180f8da3273f
For things like tempest-plugins, the cycle-with-intermediary model
is a bit overkill, especially now that we encourage multiple
intermediary releases to qualify.
Introduce a new 'cycle-automatic' model for deliverables that only
need to be released once, automatically at the end of the cycle.
This is limited to "other" or "tempest-plugin" deliverables.
Task: 31025
Change-Id: I83ff63cef18ae297013c3761a373078e580cf58b
We use release-types as a way to verify that versions are compatible and
if needed reflected accurately in the code (puppet, xstatic). If one
isn't set explicitly then we assume python-service.
In certain circumstances (anything other than the first release in a
series) we also perform python specific requirements checking on all
'python' types.
Add a new 'generic' type that uses the same rules to validate version
numbers but wont run any python specific checks.
We need this a projects (like monasca-thresh) will fail the requirements
check for 2nd or greater releases[1].
An alternate would be to have the requirements code check if setup.py
exists before calling it but that seems like the wrong layer to me.
[1] http://logs.openstack.org/54/652854/1/check/openstack-tox-validate/80df01c/job-output.txt.gz#_2019-04-16_06_08_00_636538
Change-Id: I3fcde5eb266f954fddb6871ce8690b93b8fd7a8d
Updates to use opendev.org or published documentation.
Change-Id: I0bd488b25d1259bce3f723a6c58283fdf670e721
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
This adds the new release model to the schema and updates any existing
cycle-with-milestones stein deliverables to be cycle-with-rc.
Change-Id: Ic774ce2f50dd2bb1d0e5b9976f3c7d60a98d6752
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
Now that storyboard-webclient no longer displays the project id
number in project URLs by default, it is harder for people to look
them up without referring to the API. Conversely, we could just use
the newer name-based project query support in the API instead. As a
transitional step, support both. Also switch openstack-infra/shade
from id to name to prove that the validate tool change is effective.
Change-Id: I9da97a1af40bb3527c1c7e8a66a267c76b9db564
Include stein in the index page list. This also adds support for
a "future" status since validation was add/changed since the
start of the last cycle.
Change-Id: Ie1fc997c1f5f0f3c6af1d048fcc4b25a4608e70f
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
The openstack/manila-image-elements repository has a specific
release job, legacy-manila-publishimage-generic. In order to
support release requests for manila-image-elements, we need
to create a specific release model ("manila-image-elements")
where that job is a valid release job. That will allow
manila-image-elements to drop direct tagging ACLs.
Change-Id: Ida32d45c1e5587b98eca5e4ed36880a77a92698e
Rather than requiring tarball-base be set every time in the release,
allow it to be set in the repository-settings section. The release
value acts as an override.
Change-Id: I48e424b9977a2acbfa46221da80ad0d698de8e88
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
Add an optional flags sub-element to the release, with "forced" being
the only defined flag for now.
Set the forced flag for the searchlight deliverables for rocky.
Change-Id: I9e0038f2dfd72c8ada2827289c538d85441b1cbe
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
Allow deliverables to set a stable-status value that may differ from
the series setting.
Story: #2001852
Change-Id: If5d54c317b9e1c7bc858d05bc41950eee98684fc
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
Specify that all entries in the projects list must have the repo and
hash set.
Change-Id: I9aed25d156a68f17c78945dbee9275ae636219e0
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
Add an extra check that there are no notes links for repos not related
to the deliverable.
Change-Id: I7f0fb614cff8ae38c907670da484c3c75599c7c0
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
Also rely on the schema validation to require a team setting at all.
Change-Id: I7e49a5ab717fc44d190e99bba28caa63ee54ae33
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
Add a repository-settings field for a name to override the name used
on the python package index.
Change-Id: Ie4dc2226ea0765919a9e6eb400983260094784a7
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
For now the extra validation only includes the flags list.
Change-Id: Iceb905ed84fcb76dd33708a81dc63d8ebdd3c948
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
The original thought was to have this contain rich formatting
like used in reno. But the reality is, for what this is used
for, we really just want a bulleted list of highlights for
each project.
Based on the first couple of patches, this has been a point of
confusion for those trying to use this directive. This patch
simplifies things by just treating the cycle-highlights as a
list that gets added as bullet items to the generated results.
Change-Id: If265606eb20fa3d49e3cf4a684ea683de4267927
At the end of the queens cycle we had several libraries that had no
releases at all. In order to create the stable/queens branches we
wanted to go back to the point where the stable/pike branch had been
created and tag again, raising the minor version number. This patch
updates the new-release command to compute those values automatically
when an argument of "procedural" is given.
It also extends the schema for the deliverable file to support a
"comment" field. We can't use regular source comments because there is
no way to tell the formatter to emit them.
Change-Id: I53850f55e4bae54e82b715888b33e8ea87e264d5
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
The deliverable type value is 'service', so let's use that for
consistency
Change-Id: I7118b6737800921b72ab4637fe614de29167f0fa
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
Change the 'std' release type to 'python-server' and add a
'python-pypi' release type for deliverables that are published to
PyPI.
Separate the release job validation from the validation of release
version numbers and other settings to make the logic clearer.
Add a new function to determine the release type for a project, either
by checking the explicit value or guessing.
Update the unit tests that relied on 'std'.
Remove a unit test that tested a code path that has been removed.
Change-Id: I704ec75fec61ecb6ee379239a5fa8612cb01b426
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
Be explicit about the projects that need special release jobs so we
know they are configured correctly.
See
http://lists.openstack.org/pipermail/openstack-dev/2017-October/123926.html
for more details.
Change-Id: I73307fb3233c128c8f878da89c1e850831135bc3
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
This adds the ability to provide release highlights in the deliverable
yaml file. These highlights can then be extracted and displayed into
published documentation using a new 'cycle-highlights' directive.
Change-Id: I40791dad4b5a4d2c4089e5e43d52f00b52cc3217
Require puppet repositories to have the puppet jobs and node
repositories to have the node jobs.
Update the allowed values for release-type to include "puppet" and
"nodejs" for folks who want to be explicit, but also use the module
type-detection code to default properly.
Report any jobs that are valid release jobs but for the wrong release
type as errors instead of warnings.
Change-Id: I9330cc62834f42ae0cd4d1cc48ed963846d72944
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
The Pike release script had a typo that caused the release emails to
have incorrect diff output.
This patch causes the validate test to catch more typos for releases
and branches. It also fixes the typos in the existing deliverables
files so they will pass future validation.
Change-Id: If173ba0b3d8c427f0bf5f3e4972dd0848459c951
Add a stable-branch-type called "upstream" for projects that follow
the naming conventions of another upstream project (see puppet-ceph
for an example).
Change-Id: I354bf975311c2b02c020dc83590c041c7733b041
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
Use jsonschema to define the valid structure of a deliverables file.
Retain the custom logic for some of the more complex rules we have
relating values and checking types.
Change-Id: I5dc87445c505ebd978b4c1d59171217a2fe047c7
Signed-off-by: Doug Hellmann <doug@doughellmann.com>