If a project adds a requirements check job while its requirements
files are nonconforming, they should be able to fix it by submitting
a change which fixes their requirements. If validity checks get
performed while reading requirements lists in the
gate{name}-requirements job, they need to only trigger failure while
parsing the submitted requirements and not on the existing state of
requirements before applying a proposed change.
Pass the "strict" flag through and wrap the duplicate entries check
in a conditional for it, so that we don't block fixes for projects
that start out with a duplicate requirement.
Change-Id: I16cbea930fd104717e73bd4e012ec77fc4f98494
This reverts commit 4f96b2727c2afd3c3d6b888c21c8d18ba1cb7376.
The correct fix for this is not to stop using the feature.
Change-Id: I4b35a6ca13153257984074b5145a5e691564e0ca
Currently failures of this job leave a broken comment that doesn't
match the test-result regexes, meaning that you can't see the result
in the callout box. See [1].
I863d88e9a7ed2fd41924b8fc4a12dbea3ee2b205 fixes the root cause, but
this message is still a bit wrong because it doesn't have the
[PASSED|FAILURE] bit.
I don't really see why we need this special result at all. If it
fails, you have to read the log anyway to figure out what is wrong, so
move the message pointing to the docs to where the failure actually
happens in the logs.
[1] https://review.openstack.org/#/c/292193/
Change-Id: Ie5e7d2318a510a5811c9131d56594e856da9dcc5
This reverts commit c01b96e6da166032ef13aa7ca057ab81bcc23391.
Rather than change project-requirements-change.py to support
old requirements, we'll backport changes to requirements.
Change-Id: Id6129e19988cad882629cff6c251bbaa81997d5c
project-requirements-change.py master runs against stable branches
with the stable version of requirements. requirements provides the
Requirement class that's used by project-requirements-change.py. The
stable version of the Requirement class doesn't have the `extras`
attribute, which was added in commit 33636c1d.
The workaround is to check if the Requirements object has extras and
only use extras if present.
Change-Id: I90839386dff7f28e6fa8ca7c4c56b547eaa7a541
In I78838dcd4da43b3c1d2610ac87a3ec55b9535646, we added the
ability to read "extras" from setup.cfg.
In I146baa3ef94cc8bbf29af371786f3ea95a42cb9f, we store the
list of extras specified in reqs/test-reqs.
However, the project requirements check does not use this
information yet and treats say oslo.db and oslo.db[mysql]
lines in reqs/test-reqs the same and errors out. So Nova
for example (I4131e534d4cb12e4888d398fa4fb7c922e369210) is
not able to add oslo.db[fixtures] to its test-requirements
as oslo.db is already in requirements. When we check
requirements, we should not compare the extras information
and only check package/location/specifiers/markers as
the extras are NOT present in global requirements by design.
Change-Id: I937823ffeb95725f0b55e298ebee1857d6482883
Process "extras" defined in a project setup.cfg properly by looping over
the dictionary's member items and not the dictionary itself.
Do not compare comments associated with requirements, since those are
always collected as a set of unnamed requirements and many of the
comments from global-requirements.txt are not needed in the local
project file (especially when the dependencies for which the comments
are relevant are not used).
Change-Id: I78838dcd4da43b3c1d2610ac87a3ec55b9535646
Reasoning is:
- devstack etc protect us from functional issues
- we're backporting to stable, so guarding against
aesthetics and DRY concerns is not our business anymore
- if in future we have other not-functional linty style
things to add, we don't want them to affect stable
either.
Change-Id: I8e891b8fdb6acfdf5e7e084467ee8596f51c251a
- Don't show the present-in-multiple files message unless it really is.
- Don't error on the target branch.
- Do error on the branch being submitted.
- Output what files we've looked at.
- Output what branch we're looking at.
Change-Id: I1d254c42e0bc2550ceeb768532448b5797d87caf
The rot won't be unwound for another 6-12 months, and we're not
backporting all the infrastructure to do markers to older releases. So
we need to warn only, rather than erroring, when encountering this
situation.
Change-Id: Ib63996b016f7f99f69ad1255c333cc2d1846cbdb
This switches the requirements parser from a local one to using the
reference one in openstack/requirements. To do that I install the
openstack/requirements we're testing against in a virtualenv and
import it. We could if wanted install that separately and run it
against a just in time checkout, but this should be reliable for now
(though the need to encode a python path in a venv is a little ugly).
Change-Id: I1f77a2e0eaa7046928642cf0b9e2c490a851a303
openstack_requirements has a library now. To use it we need to do all
our reading of requirements after requirements is available.
Change-Id: I53f7a16b4b28d8234192ab1845e4a337ba7a8328
If interrupted tempdirs are currently leaked. Context managers reduce
the ability for this to happen.
Change-Id: Ia7adf5f2ec8d8a327802194c88f20b22200f12cf
Testing locally with a pip installed zuul is easy with this new option
- --zc zuul-cloner and the zuul-cloner from the PATH is user.
Change-Id: Ib0c97df4be9c378bab4ff98f06c27ff771810ce9
Since run_command() already strips stdout and stderr before
returning them, there's no need to strip them again later.
Change-Id: Id5e16c57f5371dcb4a3fd532faaf52712e38c75c
The run_command() function now returns a tuple of stdout and stderr,
so its result cannot be directly manipulated as a string.
Change-Id: Ifea1c56046e74db7531cd8a687a9591424df5d6c
In the requirements checking job we need to clone the requirements repo
into the tmpdir that the test creates for the repo. Otherwise subsequent
dir changes end up failing because the dir they attempt to change into
fails.
While we are at it print the stdout and stderr written by zuul cloner to
aid in debugging.
Change-Id: Id39140ac2a0ccbaf9a9ac0f6f76350c539048670
This will use the typcial Zuul branch fallback logic. The current
branch parameter to this script is ZUUL_BRANCH, so the logic is
equivalent.
Also, adjust the test for include_dev so that dev versions are
permitted for master and feature branches.
Change-Id: I22f8d1b40c28fa3f35105da1e02574a1a0bf1556
New version of git running on review.o.o does not work with shallow
clones. But we shouldn't be cloning from review.o.o anyway. Use
the more robust git.o.o instead.
Change-Id: I4a9b4dd9da5d52e39373bee0462abaee13c462ce
Some projects do not strictly enforce requirements changes and
developers in those project need a way to see how far away they
are from the global requirements. So we need a way to run this
script to figure out which of those items in global requirements
they would like to update in their projects.
Adding a --local optional flag and defaulting the branch to 'master'
seems to support both existing usecases in gate and the local
use case as detailed above
Change-Id: I76fcea1e2965795ebb99f2b7d649cf9a53908f09
* jenkins/scripts/project-requirements-change.py: If not reading
requirements in strict mode, for example when analyzing the existing
branch tip copy of a list, allow for the possibility that
pkg_resources may be incapable of parsing what it sees as a
malformed version string.
Change-Id: I8e13a5e94901f615233ddfb4a5e4589841a01853
This repo was created from filter branching the openstack-infra/
config repo. This process brought a lot of cruft with it in the
form of directories that we no longer need. This patch removes
that cruft so we begin with a tidier repo.
Change-Id: Ibffad1b11c0c5f84eedfb0365369f60c4961a0f3
