| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes it easier to debug configuration errors when using the `zuul`
commandline tool.
For example, if your zuul.conf points to an SSH key that doesn't exist,
the error you would get before would be:
zuul.rpcclient.RPCFailure: Invalid change: 37,1
The error you get after this patch is:
zuul.rpcclient.RPCFailure: Invalid change: 37,1 ([Errno 2]
No such file or directory: '/root/.ssh/id_rsa')
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Previously zuul-cloner required that no zuul-args be set. The intent was
that all args be set or none be set and to disallow any partial setting
of the zuul args. Add the condition to allow all zuul args to be set by
allowing the length of the missing zuul args list to be 0.
Change-Id: I944f12aa1148bce7d3998b400e8d6e86fd0164d5
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Prior to this change you not only had to always supply zuul-* args or
set ZUUL_* env vars but you had to also set zuul params that were
unused. Trim down the required zuul params to only those that are used
(branch, url, ref) and only require all of them if one is set.
zuul-cloner is a useful tool for configuring git repos from a git cache
even without zuul params, this change exposes that functionality. In
particular this is handy if we ever want to run zuul-cloner outside of a
CI context, for example on a developers laptop.
Change-Id: I4f285b489df64007a6ec4c14522623f38939c74b
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The http://ci.openstack.org/ documentation site has been deprecated,
replaced by redirects to corresponding paths within
http://docs.openstack.org/infra/ where other Project Infrastructure
documentation already resides.
Change-Id: I765c42294c478d88076959462c5316a620a4f24a
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The prune() operation relies on `git branch -d -r` to remove remote
branches that are not valid. `git branch` seems to require that the repo
HEAD refer to something in refs/heads and explodes if it does not.
Unfortunately the repo reset() operation in zuul sets HEAD to point to
refs/remotes/origin/master which is not in refs/heads. This leads to
prune() breaking if run after reset().
Example explosion:
git.exc.GitCommandError: 'git branch -d -r origin/fetch_master' returned with exit code 128
stderr: 'fatal: HEAD not found below refs/heads!'
Thankfully the fix is simple. We can prune() bad refs prior to reseting,
at this point in time the value of HEAD is still valid for `git branch`
allowing prune to do its job, then we reset to the origin ref.
Change-Id: If97668f729db395fc697465d56c7d0667f994d0d
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
merger.Repo() would not clone a directory if the target path already
exists, even though it might not have been cloned. Adjust the test to
look whether '.git' exist (which can be either a directory or a file in
the case of submodules).
I came accross this issue when using Zuul cloner to clone two
repositories, one having the other as a submodule.
Given two repositories:
- mediawiki/extension
- mediawiki (having 'mediawiki/extension' has a submodule to /extension)
We run: `zuul-cloner mediawiki mediawiki/extension`
It first clone the mediawiki repository with a placeholder directory for
the submodule. The directory structure is:
.
├── .git/
└── mediawiki/
└── extension/
When cloning mediawiki/extension, ensure_cloned() would skip it since
the directory exists. Looking for subpath '.git', we trick it in
cloning the repository resulting in:
.
├── .git/
│ └── modules/
│ └── extension/
└── mediawiki/
└── extension/
└── .git # note: a file, not a directory
My use case is cloning a mediawiki/core branch which has several
extensions registered as submodules that I am not going to initialize.
Change-Id: I4fe67a1db31adc2e23e8baf57528fce76f282986
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | | |
Change-Id: Ib0cfdda5ded53af8e89aa239bd2f6e442f2537e3
|
| |\ \ \ \
| |/ / / |
|
| | | | |
| | | |
| | | |
| | | | |
Change-Id: Id3c47d4d5b70ff36098d1a9d1472e6a6fb2e89d3
|
| |\ \ \ \
| |_|_|/
|/| | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
When viewing the status page it makes sense that items with
dependencies appear as children to those changes. As such hopefully
make the grey dot description clearer that a change is only there
to be tested by the child.
Change-Id: Iadf9dee64dd143c9b6f0c4cf8786d3188a4df1d2
|
| |\ \ \ \ |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Adding a documentation entry describing the ZUUL_CHANGES parameter
that is provided to builds associated with changes.
Change-Id: I57be39b8b795edfb1f636db9469c18008afc14a5
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
When embedding this into a branded dashboard with other pages
it is preferable not to add custom hooks into these files but
instead call zuul_start and be able to attach additional event
handlers to zuul.app.on() or zuul.jq.on().
Used on https://integration.wikimedia.org/zuul/ and would likely
be needed on http://status.openstack.org/zuul/ in the future
as well.
Change-Id: I77d935d67051d50d38db5a002f4bf766c4371731
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The gerrit event processing thread performs its own queries and
updates of change objects outside of the main thread, possibly
while those objects are being used in the main thread. Generally
this is okay because typically only new data are being added to
changes, and if any of the new data are relevant, the main thread
will receive an event about it and update accordingly.
However, in the process of updating changes in the event processing
thread, some attributes of the change may be temporarily set to
incorrect values, such as empty lists. Switch to atomic updates
of those values so that if the main thread consults the change object,
it has reasonably valid values.
This may have caused sporadic failures of test_dependent_changes_dequeue,
but is also capable of happening in production.
Change-Id: I134d50fe2da8ef344ee8d4fb68a1eed0692b04e2
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The previous fix was insufficient because multiple merge jobs
could be run at once. Using the new orderedRelease method however
should be sufficient, and it ensures only one job runs and finishes
at a time.
The previous code was more appropriate for a test of a gate
pipeline and was probably copied from it.
Change-Id: I0534c7ce6dd473cb71ba37c8c0fedef8e5ca72a5
|
| |\ \ \ \ \ |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This test depends on an ordered build history, which means that we
need to control when the builds are complete (with the worker),
rather than when they start (with gearman).
Change-Id: Ib667ddf2a60a473f02d0e85f227862997e459c3d
|
| |\ \ \ \ \ \ |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
NullChange returned equal for any change in the project, now
only returns equal for a NullChange (_id None) in the project.
Also added test case for the issue.
Change-Id: I4e43d1aa6cb040f775308f18333e090ff20e0dc0
Closes-Bug: 2000223
|
| |\ \ \ \ \ \ \
| |_|/ / / / /
|/| | | | | | |
|
| | | |_|_|/ /
| |/| | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Follows-up aa4f2e7. While we're sending Last-Modified already,
that's purely informational and doesn't do much.
In theory proxies could figure it out by observing or polling
the backend (with rate limiting) but afaik that isn't generally
implemented.
Web browsers typically send If-Modified-Since. So for requests
coming from the users directly, Response.conditional_response_app
handles the If-Modified-Since header and returns early with
HTTPNotModified if needed (and no body content).
In addition Cache-Control/Expires headers allow clients/proxies
to handle it themselves (without even a 304 rountrip). This is
preferred and informs the client of the actual expiry instead of
having it ask us every time whether or not a timestamp is too old.
Response:
200 OK
Cache-Control: public, must-revalidate, max-age=(seconds)
Expires: (RFC 2822 timestamp + seconds)
Last-Modified: (RFC 2822 timestamp)
Request:
GET
If-Modified-Since: (RFC 2822 timestamp)
Response:
304 Not Modified
Expires: (RFC 2822 timestamp + seconds)
http://docs.webob.org/en/1.1/modules/webob.html
Change-Id: I51f31f9d7965d805e147fda4070feead528601ac
|
| | |_|/ / /
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
There is no API or behavioral change required, but gear 0.5.7 has
significant performance improvements, enough so that it is required
for OpenStack's installation, so bump the requirement here.
Gear 0.5.6 has a regression that causes Zuul tests (but not actual
operation) to fail.
Also includes an unrelated test race fix: the order in which jobs
completed in the test_crd_check_git_depends test was random. Switch
to releasing them in sequence for easier comparison with the build
history at the end.
Change-Id: I281356a620c017a546ec04a0a767cf34c1fc62bf
|
| |\ \ \ \ \
| |_|/ / /
|/| | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
zuul-changes.py does not accept --review-host param
since 574ec76a6085b13fb1f02697e68baea7cc0bb63b
It's usage output is:
usage: zuul-changes.py [-h] url pipeline_name
Correct the docs to match.
Change-Id: Iab8158f73f6b1611d088377e36a7d076907bf8f6
|
| |\ \ \ \ \ |
|
| | | |_|/ /
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The CRD duplicates test was removing the job hold flag which meant all
FakeBuild threads were racing each other to update the FakeWorker
history. Avoid this by releasing jobs for one change at a time and
letting them settle before checking the job history list.
Change-Id: I86ee058546d2f0b833106725b419a8adcb1b7508
|
| |\ \ \ \ \ |
|
| | | |/ / /
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The check for whether all outstanding builds are waiting (which
means the system is stable and may be examined) did not account
for builds which may have just started running but had not reported
their start back to Zuul. This means that the test system could
determine the system had settled while a job start packet was
in-flight. This has been seen to cause the test_abandoned_gate
test to fail due to the inconsistent state.
Since this race can occur in reality, also update the launcher
itself to more gracefully handle this condition.
Change-Id: I734094514db294564f6526e42b801a7e1d22a021
|
| |/ / / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
When querying a change immediately after a patchset upload, Gerrit
may return incorrect data about dependent changes. In order to
avoid this, ensure at least 5 seconds have elapsed before delivering
any Gerrit events to Zuul.
Change-Id: I95c459f52562556ca1722878e32388d51033e86c
|
| | |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In order to find reverse dependencies specified by cross-repo
"Depends-On" headers, search for the occurance of a given change-id
in commit messages, and then filter the result set for "Depends-On"
headers.
Add those cross-repo reverse dependencies to the already supplied
Gerrit git reverse dependencies. This should cause behaviors
such as automatic enqueuing of reverse dependencies on merges to
apply to CRD as well as git-dependencies.
When collecting reverse CRD, update cached Zuul change records.
This corrects a bug where if change A depends on B in a different
repo, and change B is updated with a new patchset, Zuul's cached
record for change A will still point to the old patchset of change
B. This change corrects that by causing B to trigger a refresh of
A when the reverse CRD is noted.
Change-Id: I1bcf1f0fa0ea1c20b01ea478a83f179b612a0ae9
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
When a merger receives a job, log the uuid for better correlation
with the zuul server.
Change-Id: I589c0435b17ed4f85e33cc2049c88e695e20d764
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When submitting a job to the mergers, log more information about
the job. Specifically the UUID will now be included for easier
cross-correlation with completion events.
Change-Id: Id92ae0c73f725da23761c59c97f0d39d64e802a9
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Rather than just updating the repository, have zuul.Cloner update, reset to
remote HEAD, and remove untracked files.
Change-Id: I6813c84ebf7ce5fc87ffea390e035fd19597d71c
|
| |\ \ \ \ |
|
| | | |/ /
| |/| |
| | | |
| | | | |
Change-Id: I1e07978f12341214301f1e4b01f0b57047794728
|
| |\ \ \ \ |
|
| | |/ / /
| | | |
| | | |
| | | | |
Change-Id: I990cd0282f8e6d7706dc1bb6b6573b929623a171
|
| |\ \ \ \
| |/ / /
|/| | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Some swift parameters are integer in type and they do not support the
string format operation. Only format parameters if they are a string and
pass integers (and other types) through as is.
Change-Id: I8d7a5bb25f7be00a5cb02b81292a548f033cad8a
|
| |\ \ \ \ |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
They don't have anything particularly sensitive now, but they might
in the future, and they can be quite large (thus making status.json
large).
Since the zuul client command uses the same data, remove the
parameters column from its output.
Change-Id: I681c576a25012a6fb0733f468778576d6003c088
|
| |\ \ \ \ \ |
|
| | | |/ / /
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
If a non-live change was removed from the queue because one of
its dependencies was removed, do not report on that change. The
live change will eventually be removed for the same reason and
it will report. Once is all that is needed.
This should not normally happen, but we have seen it occur when
dependencies have somehow changed behind zuul's back, possible
because of an error in Gerrit.
Change-Id: Ibb8daafb064e841606083d648b81389966d5333e
|
