This is independent + change-merged. With files matchers, promote
is actually problematic because we'd elide sets of different
changes potentially missing triggers.
Use deploy pipeline for project-config deployments
These all have files matchers which makes using them in promote
problematic due to deduplication.
Change-Id: Ic77cdb2aab359b20b9c8b3a66ee031d24f7c95a0
The release-approval pipeline uses a username filter in the
comment-added trigger so that comments from 'zuul' username would
not trigger it. Unfortunately, the regexp also matched usernames
which contained a dot, like 'rico.lin'.
Fix the regexp so that it matches 'ttx', 'rico.lin', 'zuulfoo' and
'zuul.bar', but not 'zuul'.
See tests for the old and new regexp at:
http://paste.openstack.org/show/791583/
Change-Id: I6834f71b52570310735f202984af8f7f6ce701a1
Until we can trigger jobs when zuul publishes new images, we should
run a few of our infra-prod playbooks on an hourly cron to keep up
with changes.
Change-Id: I08525729ec30b5f565f1858a357591503dd2a215
We really are done (as I write this) with debugging this. We were
unable to reproduce the error.
This reverts commit 4b53515189.
Change-Id: I0c210a830dba710c71e364834a98c098d78ae595
This reverts commit 9e9aeff0fc.
We were not done debugging. In fact, we hadn't even started debugging,
so revert the revert of the job removal. Here's the justification for
the original revert:
We had a job trigger that shouldn't have. Re-add the job so
we can debug why that happened. Because we're debugging, turn of
all github reporting.
Change-Id: Idb16bcf5b581e7dd411506eb69c2324e206f0511
We're done debugging now, re-revert the ansible job and
re-add reporting to github.
This reverts commit 5d674d3b4f.
Change-Id: I95edc2c0ae2a523dda59894c4a033ea1ee08845e
We had a job trigger that shouldn't have. Re-add the job so
we can debug why that happened. Because we're debugging, turn off
all github reporting.
Revert "Stop running against devel of ansible/ansible"
This reverts commit 594efcf712087db8a55c553bcb48e89fa638154.
Change-Id: I52ee1533fea0fcbf68eaee3a73c0e666a284f3c3
Adds a periodic pipeline which runs weekly in addition to the current
one that runs daily, which is too often for some jobs.
Change-Id: Ib1bd96a3ace6920479137f99cb0c581dccb13e3c
Since it rus on every (human) comment, the release-approval pipeline
can get pretty noisy. It's also not that critical to read (failure
generally meaning that you don't have the required +1s yet).
This change disables comment posting on success/failure in the pipeline.
Change-Id: I4808a84cd39a5a19ddad86b548ec18d8cadf7430
The release-approval pipeline implemented a nice infinite loop as
it was triggered by all comment-added events, and Zuul is posting one
every time the job runs.
Add a regexp to exclude comment-added events from the 'zuul' user.
Also since patchset-created actually does not trigger comment-added,
it needs to be specified separately (in order to approve releases
proposed by the PTL themselves).
Change-Id: I0f8b8526adaa83876ff92a98500d35c70cc23174
Define a release-approval pipeline to run the check-release-approval
job on every comment added to a release request, and set a
PTL-Approved label accordingly.
This may be considered a bit resource-intensive, however the
check-release-approval job is a fast python script that runs on
the executor, and only release requests shall go in this pipeline.
If this generates too much load, we could configure it to only run
when the comment posted contains a magic "signoff" keyword.
Another concern is that jobs other than check-release-approval would
be added to this pipeline. There does not seem to be a way in Zuul to
limit a pipeline to a specific job name or project.
Change-Id: Ieab04a4d6c02b216a59c12ec8599e7d91f4fffb1
ARM64 testing is of interest to a number of projects. For example:
https://review.opendev.org/662456 : kolla
https://review.opendev.org/676111 : diskimage-builder
https://review.opendev.org/690798 : system-config (mirror tests)
However, we have been hesitant to put these tests into the main check
queue because with only a small number of nodes available (8
currently) it may lead to long delays merging code.
While jobs could go in the on-demand experimental pipeline, this
doesn't quite reflect the status of the jobs and nodes which are
operational.
I think that a separate queue to allow these jobs to run
automatically, but asynchronously to the regular check queue is a good
option here. This will be a step to build a strong track-record for
the jobs without affecting the main gate, which should hopefully lead
to more interest and potentially more resources.
Change-Id: I77aac13521049496d43758121788aa44f0ecc990
Our old log urls had ref info in them which people were relying on to
determine what refs jobs reported via smtp ran against. With changes to
the zuul dashboard being the log location the links now only have a
build uuid and lack ref info.
Update the pipeline smtp reporter subject to include the change.ref
object which should give this info to users again.
Change-Id: If81710baa528be779762730e9593b32841ffcb56
Change I45cb34c29d86ca67e75604f6ac3b8af6758f6242 updated the priorities
of pipelines so that they become progressively higher, this change
is not reflected in promote pipeline. Promote pipeline
should have the same priority as the post pipeline, thus update it and
change promote to high precedence.
Change-Id: Ia921f0e191c0526be9a102629304034b68054d98
This reverts commit 24221d2c0b.
This hasn't had a noticeable impact on the check queue backlog. It is
still floating around 2 ish hours. We may as well go back to larger gate
windows in an attempt to merge more code.
Change-Id: I1b8b90ce371e66cbde63f0f7a62b9aebe0401835
Both the tripleo gate and the openstack integrated gate are incredibly
flaky and they use up a good deal of test nodes. To mitigate the impact
of this on the check queue and for people not working on either set of
queues reduce the window floor to 10 from 20.
Change-Id: I05aa65a132c272ad6bf60e44c82e0dd24b53bb8b
There is confusion around why jobs that have already passed are
restarted after a gate reset. There has also been some confusion around
jobs not starting for inactive changes outside of the gate window.
Attempt to address some of this by explicitly linking the gating docs
for zuul from the gate pipeline description which will show up in the
Zuul Status page UI.
Change-Id: Id2451c813f5e5ea6595a3375f83ae9b49ca8dcd2
This patch changes the precedence settings for pipelines so that they
become progressively higher. Under high load, this is expected to have
the effect of prioritizing jobs needed to "finish" one patch
completely over jobs related to patches that are not as far along in
the approval process, which should prevent the post and gate pipeline
queues from backing up at the expense of making the check pipeline
queues deeper.
Change-Id: I45cb34c29d86ca67e75604f6ac3b8af6758f6242
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
We've insisted in the past that "core developers" aren't a thing, so
if we want to avoid continued propagation of that terminology then
we should do our best to avoid using it in Zuul pipeline
descriptions.
Change-Id: Ifbebf824716e4a4d1bab4eb194a8b6e8b4fedd5f
Update the post (and promote) pipelines to use the supercedent
pipeline manager. This will cause only the latest versions of
artifacts to be published, rather than having multiple jobs
racing.
https://zuul-ci.org/docs/zuul/user/config.html#value-pipeline.manager.supercedent
Change-Id: I2db1024b67d40ea3203f3636a61fe2ae7e09ff46
This is for a demonstration of how we could promote some artifacts
directly from the gate pipeline without generating them in post.
Change-Id: Id60b5e292b5750d701ec77b51ff73f12becf3cbd
Some may consider it confusing that most jobs on zuul.openstack.org are
named after their review numbers, but `post` jobs aren't. This change
adds words to the description of the post queue indicating that jobs are
named after the abbreviated version of the commit hash of the merge.
Change-Id: I8a304b302d13468f6cbb73edadf60c6667ec32e3
With the shutdown of tripleo-test-cloud-rh1 we no longer have any jobs
that use these pipelines. Jobs that did run, have been moved to 3rd
party CI. Hardware and cloud are also lacking maintenance and soon to
be removed.
Change-Id: I28111b0287b23370fa137a8d0d5731e013889260
Depends-On: https://review.openstack.org/536461/
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
Currently merge failure reporting is pipeline global. That means we wind
up reporting merge failures on ALL changes to third-party github
repos, even if the change is touching files we would not otherwise
normally test.
Add a new pipeline for external projects that does not report merge
failures.
Change-Id: I5a65cf9babdf37b385e321f350752124c3e1de1e
The Zuul MySQL database is one of the only ways we can get fairly
precise historical metrics for the jobs that run in all the pipelines.
However, we're missing a significant amount of data right now by
leaving out the experiemental, check-tripleo and
check-tripleo-experimental pipelines.
Let's start recording those so we can make informed decisions with
numbers easily in the future.
Change-Id: I0daeff1f6c6d4527cbd17f55c2df242e1ecb8b33
Our Gerrit no longer has any "jenkins" account verified votes on
open changes, so there is no reason to consider it in our pipeline
configuration. Remove the reference and simplify configuration.
Change-Id: I80bc50c4dc6c41c732051e57c78230a18c3673af
This is no longer used anywhere, lets delete it.
Change-Id: I965ea859de43fb4d4bd4b682b56a67167c170af7
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
Remove infra-gate and infra-post; remove infra-check everywhere except
for project-config so that we can quickly iterate on it.
Enable the pipelines for all projects.
Move infra-check pipeline after check to have those related pipelines
displayed together.
This partially reverts I084b819ea0a4b67f36df61ccb3bfd6963cc3940d and
reverts Ieced5db4bb8a29eb494dffce3bed030a528f46a1 and
I5646ab81eb1a6515b32c42a2c3c4e64a94be4748.
Depends-On: I738f7c48b8f47e05c95de645a2d3403363204737
Depends-On: I48b14f2d26972cc06ab2293885b37b61c687e83b
Depends-On: Ib325a20839db3fe7884564db2a877ff4edb920e2
Change-Id: I8ed5d777f077b4ebda42c57a5871f38bd1762f88
Enable check-tripleo, periodic and check pipelines again for normal
jobs.
This reverts the following commits:
I7734b9f691f039182d68563b46c8b529c39f32c7 "Disable trigger for v3
check-tripleo pipeline"
I13f772618b4e93591ed233a69296e5f51eb88414 "Similarly to disabling check,
disable periodic"
I4c7f14c8dd5bc054704f02451b2d40919ce69416 "Disable zuulv3 check
pipeline"
Change-Id: I8427ac7c4f9629141162849ec8815c8b5d43f05f
We do not want to allow this job or its children to run without
code-review having happened. Mark it, and the non-speculative pipelines,
as post-review.
Change-Id: I8c8a936798f86283bb4e262164641857b2d6edec
We need to get job log filesystem inode consumption under control so
stop running these periodic jobs on zuulv3.
Change-Id: I13f772618b4e93591ed233a69296e5f51eb88414
In an effort to get inode consumption under control on the job logs
filesystem stop running check jobs in both v2 and v3. We will only run
in v2 for now.
Change-Id: I4c7f14c8dd5bc054704f02451b2d40919ce69416
Do not allow a single +1 by jenkins to start the gate process, we should
require a +1 by zuul only.
Change-Id: I0808d27c139609cfce42f1e9d794cac94bb55cb5
We're not collecting mysql reporter information for pipelines other than
check and gate ... but post and tag and friends are actually super
important for collecting the data.
Change-Id: I198bcbf57a6020d24c476070e42a9b0dd3abf32d
Change the pipeline config to include invalid requirements for all
non-check pipelines so that we can keep project-pipeline configs but not
have any changes be enqueued in them. This should allow running v2 and
v3 side by side.
Add infra- versions of gate and post so that we can continue to use v3
to gate zuul, zuul-jobs, openstack-zuul-jobs and project-config.
Change-Id: I084b819ea0a4b67f36df61ccb3bfd6963cc3940d
* It uses merger resources, and Gerrit shows up merge conflicts now.
* It performs speculative configuration on changes with config
updates, which is expensive.
* In some cases, it can race with reconfigurations to report false
failures on config changes.
Change-Id: Ic5bbc60e6a0aa19799a903fd5ada7bbe3846bf90