| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The github pipeline reject docs mimic the Gerrit reject docs which
have an asymmetric require/reject setup. GitHub requirements are
symmetrical, which leaves the docs incomplete.
Correct that by copying the `require` section to `reject` with
a few tweaks.
Change-Id: If0ac228b9246817e71d9038039fcc1eead1c8571
|
| |\ \
| |/ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This adds the "draft" PR status as a pipeline requirement to the
GitHub driver. It is already used implicitly in dependent pipelines,
but this will allow it to be added explicitly to other pipelines
(for example, check).
This also fixes some minor copy/pasta errors in debug messages related
to github pipeline requirements.
Change-Id: I05f8f61aee251af24c1479274904b429baedb29d
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Some test failures originate due to an apscheduler thread that is
still running. Add some debugging to the timer driver to try to
help identify if there is a problem with the start/stop sequence.
Change-Id: Idcaf7ac0adfff737d88d2f42fcc4e1305bfea607
|
| |\ \ \
| |/ / |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Some tests are failing to settle because the ZK queues are not
empty, but it is not clear which queue, and that makes the trouble
hard to track down. Add debugging around this to try to understand
the problem more.
Change-Id: I5012dec9f80e5413c5303698325d510554d22d3a
|
| |\ \ \
| |/ / |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If a reconfiguration happens after the timer connection is stopped,
we should not restart the apscheduler; that can lead to zombie
threads.
We should not perferm a reconfiguration after stopping the connection
anyway, so to correct that, change the shutdown sequence so that we
stop the layout update thread before we stop the connections.
Change-Id: If9c387dfc42fcba7de3969d81cf2c7917d7e4fa3
|
| |\ \ \ |
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
A change's topic so far was not stored in with the change in Zookeeper.
Due to that the Gerrit dependencies-by-topic feature wasn't working
in a multi-scheduler setup.
Change-Id: I815e90607d839886921b61625075b3df96ca0bbd
|
| |\ \ \ |
|
| | | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | | |
This was introduced with I0273993c3ece4363098e4bf30bfc4308bb69a8b4.
The variable being checked is "zuul_console_disabled". Correct this
in the documentation.
Change-Id: Ib45ec943d4b227ba254354d116440aa521fb6b9e
|
| | |/
|/|
| |
| |
| |
| |
| | |
Ansible 5 is no longer supported and 6 is available and working.
Deprecate Ansible 5.
Change-Id: I8c152f7c0818bccd07f50e85bef9a82ddb863a68
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This uses react-app-rewired and react-app-required-esbuild to replace
Babel with esbuild to build zuul-web. We do this to speed things up as
Babel is quite slow (6 minutes or so in CI) and esbuild should be much
quicker.
Change-Id: If8f59c0e93e3b8c963ac967e93ffe52b6ba54e06
|
| |\ \ \
| |/ /
| | /
| |/
|/| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The Zuul unittest jobs were timing out which prompted me to take a look
at what might be taking extra time. One thing I noticed is that we're
running the yarn build (which runs react-scripts) multiple times when we
really only need to run it once. The reason for that is our check to see
if zuul web has already built is looking for a file that the builds no
longer produce. Update that check to look for a current file and we'll
save a bit of time in our jobs and when running things locally.
Change-Id: Iae3604fbaf072d53895db850cfc989a832b12b27
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The node request span needs to be ended whenever we add a result event
to the pipeline. Before we only did that when iterating over the node
requests after we've won the nodepool election.
Change-Id: I0276d5498b243522540657352a733d663ae71918
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
In a job nodeset, you do not need a "name", but some of the error
logic assumes it.
This leads to a rather confusing error return; for example something
like
job:
...
nodeset:
nodes: []
groups:
- name: a_group
nodes:
- a_node_that_does_not_exist
leads to
Zuul encountered a syntax error while parsing its configuration in the
repo opendev/system-config on branch master. The error was:
'name'
when really it is trying to tell you is that "this_node_not_defined"
isn't defined, but it tries to de-reference the name of the nodeset:
and fails.
This keeps track of the anonymous nodeset flag and if set, then
rewords the error to make sense in the job context; for example it
will now say:
Zuul encountered a syntax error while parsing its configuration in the
repo org/project on branch master. The error was:
In the nodeset the group "a_group" contains a node named
"a_node_that_does_not_exist" which is not defined in the nodeset.
The error appears in the following job stanza:
job:
name: test job
nodeset:
nodes: []
groups:
- name: a_group
nodes:
- a_node_that_does_not_exist
Test cases are added to cover the updated messages.
Change-Id: Ia24e66ba9b97618636023cb61d7c82aa7306d678
|
| |\ \ \ \
| |_|_|/
|/| | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
In some recent changes I've been looking at the narrow view of the
console page. One thing that remains inconsistent is the magnifying
arrow; it can jump around depending on the page width and in my
subjective opinion it looks a little out of context.
This proposes making a single "pill" for the status and magnifying
icon. The width should be consistent, and the magnifying glass
floating right behind a divider to inidicate it is separate to the
status -- it is also set to not break so it stays together.
Change-Id: I183d4c939a1c74e21198564d1d51e33ecdbc813c
|
| |\ \ \ \
| |/ / /
| | | /
| |_|/
|/| | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Currently this displays the task OK, Changed and Failure(s) results in
a traffic-light format. I've been looking at the way some other
similar tools present this sort of info, and I think that a few things
stand out
- the orange for the "changed" status is a bit of a red-herring,
because it suggests a warning but really a changed task is as
"good" as an OK task.
- Secondly, the failure case doesn't stand out enough; failures are
going to be the cause of problems, but you get the same
traffic-light for hosts that ran successfully and failed.
- When nothing has failed, we show "0 failures" -- but that is pretty
much implied by things working. It's a bit redundant and puts up a
red box when there isn't a failure.
This proposes moving into a single tasks results label that is either
green for success, or red if there are failures. If there are no
failures, you just see the count of OK/Changed tasks -- if there are,
you'll also see the failed count.
Change-Id: Iebadc4ddb77209f69242ebc5ac46f2ae6d67789f
|
| |\ \ \
| |/ / |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
To keep consistency with the console page
(I6df896497f3a20d639fc67f256e1d2566aa2903c), put the failed tasks in a
light red box to highlight the failure case.
Change-Id: I48e1b616663919787fb52d53ee27882efea825f9
|
| |\ \ \
| |/ / |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
To give more visual weight to a failed task, give it the lightest red
background.
Change-Id: I6df896497f3a20d639fc67f256e1d2566aa2903c
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | | |
Change-Id: Idb9b673542c2054f7bbae094ad5702a472197fe1
|
| |\ \ \ \ |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Clarify the comment from I8a7e8172f784fc69aa0abb2e6787c63c33d3f802 to
make it clearer that we have only seen this behaviour with package: on
yum/dnf/Redhat-ish platforms.
Change-Id: Idc14c5799f0c8e66440f23b175780a00c82bd589
|
| |\ \ \ \ \ |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Old link is broken.
Change-Id: Ie7f476cfcc4dded2fb7418aefac0692132ca10d8
|
| |\ \ \ \ \ \ |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This updates the OpenAPI docs to include the semaphores endpoint,
and adds a Semaphores tab to the web UI to show information about
semaphores within a tenant.
Change-Id: If78b27131ac76aff93c47a986fce6eae3e068668
|
| |\ \ \ \ \ \ \
| |_|_|_|/ / /
|/| | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
We get a trace from every merger (including executors) for every
merge job because we start the trace before attempting the lock.
So essentially, we get one trace from the merger that runs the job,
and one trace from every other merger indicating that it did not
run the job.
This is perhaps too much detail for us. While it's true that we
can see the response times of every system component here, it may
be sufficient to have only the response time of the first merger.
This will reduce the noise in trace visualizations significantly.
Change-Id: I88c56f00c060eae9316473f4a4e222a0db97e510
|
| |\ \ \ \ \ \ \
| |/ / / / / / |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This (especially the pipeline name) may help us narrow down what
we're looking for when there are multiple queueitems for an event.
Change-Id: I4e5c53d6379f6501730fab6d599a37c0965f2287
|
| |\ \ \ \ \ \ \ |
|
| | |/ / / / / /
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Change I216b76d6aaf7ebd01fa8cca843f03fd7a3eea16d unified the
service stop sequence but omitted changes to zuul-web. Update
zuul-web to match and make its sequence more robust.
Also remove unecessary sys.exit calls from the merger.
Change-Id: Ifdebc17878aa44d57996e4bdd46e49e6144b406b
|
| |\ \ \ \ \ \ \
| |/ / / / / /
|/| | | | / /
| | |_|_|/ /
| |/| | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
I've noticed that when making the console page very narrow (mobile)
the entries are difficult to differentiate in their compressed form.
This proposes adding alternating colors on the play entries to
differentiate them. Since the grey is used between elements, the
highlight is modified to the the lightest blue in the PF family.
Putting a small border-radius on this makes it look a bit more
differentiated.
Change-Id: I7afcb64a5e41348f14bd297c8c8bde27312dff97
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
When we made this change the release notes made note of it, but the docs
for the extra vars job attribute did not. Update the job attribute docs
to clarify this behavior as well to avoid any confusion.
Change-Id: I83b5f7c0a26ffb40e413e02ad2463434e5780fc5
|
| |\ \ \ \ \ \ |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Start a span when creating Zuul trigger events when a change is merged
or enqueued. The span will be linked to the span of the queue item that
was enqueued or merged.
Change-Id: I3870ef2755136a9e8684494da69aefc5f426728e
|
