Compute the dependency set for the python code being released and
report when the old minimum version no longer falls within the
specified range. For releases from master treat the message as an
error. For other branches treat the message as a warning.
Update clone_repo() to return the location where the clone was written
as a convenience to the caller.
Extract the logic for determining if a version is using
pre-versioning (alpha, beta, etc.) so it can be reused.
Change-Id: I22a2f6df7f3502e4fcbf2d61ef5fee849ab15529
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>
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>
Note that this is the first time openstack-manuals is using this
process. Since 2012, the team only created branches. Since
openstack-manuals now uses reno, let's branch and tag together.
We use 15.0.0 as release number since Ocata is the fifteenth release of
OpenStack.
Note that openstack-manuals has no release-job, we do not push the
content anywhere, just publish.
Change-Id: I0f92f2bf6c563e9ca71fdfba5e00da73d3a98fc7
Pre-versions are only OK if you're using a release model
that allows for them (like cycle-with-milestones). Now that we
have the information in the releases file, move the warning
in list-changes to a proper validation failure.
Change-Id: Ifb91bd2446b6d37dc9bb4601cad28f29c065c2e8
Add version number verification rules for release-type==fuel, matching
the standard rules.
Make the error message that's reported for an unknown release-type
clearer.
Change-Id: Ia32b7badc36f29a70c3c8b5aa32649dd9e129026
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
When trying to use the history import tools we need to use the correct
release-type setting to validate tags.
We can't use versionutils.validate_version() as it's a generator which is
hard to use in a sorted() function. Insetad introduce
versionutils.canonical_version() which will return the version is valid
or raise a ValueError() exception.
Change-Id: If10aab4c573342227e2909fd84f843c96f3abc43
The xstatic packages have a 4 digit verion number 3-digit semver as
supplied by upstream and a local build number. PBR only supports 3
digit semver.
To work with that create the concpet of a release type that can have
slightly different validation rules. In this case use the 'packaging'
library.
This will allow the horizon team to use the standard release process.
For refernce see:
https://blueprints.launchpad.net/horizon/+spec/xstatic-release-process
Change-Id: Ie0f33097c31ee4006ec58147b35731913f7b6f4b
