Commit Graph

1620 Commits

Author SHA1 Message Date
Zuul 56a73f86eb Merge "Fix github docs for pull_request_review.state" 2024-03-25 19:53:18 +00:00
Zuul a3abea408b Merge "Emit per-branch queue stats separately" 2024-03-25 19:22:37 +00:00
Zuul 3b19ca9cb3 Merge "Add zuul_unreachable ansible host group" 2024-03-25 18:26:14 +00:00
James E. Blair 632839804c Add a zuul.buildset_refs variable
This adds information about the changes associated with a
circular dependency queue item.  Currently the bundle_id can be
used to identify which of the items in zuul.items is related to
the current dependency cycle.  That variable is deprecated, so
zuul.buildset_refs can be used to replace that functionality.

Since it repeats some of the information at the top level (eg
zuul.change, zuul.project, etc), the code is refactored so they
can share the dictionary construction.  That is also used by
zuul.items.  This results in a few extra fields in zuul.items
now, such as the change message, but that is relatively
inconsequential, so is not called out in the release notes.

The src_dir is similarly included in all of these places.  In
writing this change it was discovered that
zuul.items.project.src_dir always used the golang scheme, but
zuul.project.src_dir used the correct per-job workspace scheme.
This has been corrected so that they both use the per-job scheme
now.

A significant reorganization of the job variable documentation is
included.  Previously we had a section with additional variables
for each item type, but since many of these are duplicated at the
top level, in the item list, and now in the refs list, that
structure became difficult to work with.  Instead, the
documentation for each of these sections now exhaustively lists
all of the possible variables.  This makes for some repitition,
but it also means that a user can see at a glance what variables
are available, and we can deep-link to each one.  To address the
variation between different item types, the variables that mutate
based on item type now contain a definition list indicating what
types they are valid for and their respective meanings.

Change-Id: Iab8f99d4c4f40c44d630120c458539060cc725b5
2024-03-22 06:41:36 -07:00
James E. Blair 91e22dfa96 Fix github docs for pull_request_review.state
The schema validation for these values is correct (if a little
generous) but the docs had some incorrect example values.  Update
them to match the schema.

Also, add comments to the schema validation indicating the source
of these somewhat mysterious values.

Change-Id: Idf26848a8c121d311590d07e003b53b8e867affd
2024-03-14 08:00:32 -07:00
James E. Blair 802c5a8ca6 Use the triggering change as the zuul change
In the case of circular dependencies with job deduplication, we
arbitrarily pick one of the changes as the zuul change (to use
when setting the zuul.change job variable and friends).  In
theory, it shouldn't matter which change we use, but in practice,
users may be surprised if it is something other than the triggering
change. Since it doesn't really matter to Zuul, let's set the zuul
change to the triggering change when possible.  It still needs to
be one of the changes for the job, so if the triggering change
itself doesn't actually run the job (easily possible if the job is
only run on dependent changes), then we will fall back to the
current behavior.  And of course the change must be one of the
item's changes, so in the case of linear dependencies, we're not
going to start setting it to some other queue item's change.

If we are unable to set it to the triggering change, then the
behavior remains undefined beyond setting it to one of the job's
changes arbitrarily.

Included in this change is a cleanup of a no-longer-needed api
migration from 12->13 related to EventInfo objects that was
missed due to a missing MODEL_API tag.

Information about the triggering change is added to the EventInfo
object to implement this feature.

Because the fallback behavior and the model upgrade behavior are
the same, we don't need to add any conditional api behavior or
upgrade testing -- in both cases we will simply use the current
behavior.

Change-Id: Iee5a7d975fea1f7491b652c406c24d73ada7a1a1
2024-03-13 13:07:08 -07:00
Joshua Watt d5dcb7eb35 Report topic to jobs as zuul.topic
Reports the change topic to jobs as an ansible variable. This can be
useful for jobs that either want to name artifact output based on a
topic, or enforce that a topic is set using a zuul job.

Change-Id: I678404523d228947541160554623bf4066a729c4
2024-03-08 11:30:45 -07:00
James E. Blair 794545fc64 Emit per-branch queue stats separately
We currently emit 4 statsd metrics for each shared queue, but in
the case that a queue is configured as per-branch, we disregard
the branch and emit the stats under the same hierarchy for any
branch of that queue.  This means that if we have a queue for
integrated-master and a queue for integrated-stable at the same
time, we would emit the stats for the master queue, then
immediately emit the same stats for the stable queue, overwriting
the master stats.

To correct this, move the metrics down a level in the case that
the queue is configured per-branch, and include the branch name
in the key.

Change-Id: I2f4b22394bc3774410a02ae76281eddf080e5c7f
2024-03-06 06:32:22 -08:00
James E. Blair 79a9f86c8d Ignore circular dependencies in supercedent pipelines
There are two issues with supercedent pipelines related to circular deps:

1) When operating in a post-merge configuration on changes (not refs), the
   pipeline manager would throw an exception starting with 10.0.0 because
   any time it operates on change objects, it attempts to collect the
   dependency cycle before enqueing a change, and starting with 10.0.0,
   the supercedent manager raises an exception in that case.
2) When operating in a pre-merge configuration on changes, the behavior
   regarding circular dependencies was undefined before 10.0.0.  It is
   likely that they were ignored because the manager creates a dynamic
   queue based on the project-ref, but it wasn't explicitly documented
   or tested.

To correct both of these:

Override the cycleForChange method in the supercedent manager so that it
always returns an empty cycle.

Document the expected behavior.

Add tests that cover the cases described above.

Change-Id: Icf30d488334d40a929f31c2f390e18ae599a3c42
2024-03-04 10:50:23 -08:00
Zuul 3d30928d39 Merge "Add some github configuration deprecations" 2024-03-01 18:54:10 +00:00
James E. Blair 171d4c56b1 Add some github configuration deprecations
The "event" trigger attribute can currently be a list.  Technically,
it is possible to construct a trigger with an event list, such as:

    trigger:
      github:
        - event:
            - pull_request
            - pull_request_review
          branch: master

Which would trigger on any pull_request or pull_request_review event
on the master branch.  However in practice users typically have much
more narrow event selections, such as only triggering on pull_request
events with the opened action, or a pull_request event with a certain
comment.  It is not possible to construct that example with a single
trigger; the following is invalid:

    trigger:
      github:
        - event:
            - pull_request
            - pull_request_review
          actions:
            - opened
            - commented
          branch: master
          comment: recheck

That will pass syntax validation but would only fire on a recheck
comment; it would never fire on a PR opened event because that event
won't have a comment.

To help users avoid these problems, or worse, let's limit the event
specifier to a single event (of course users can add more triggers for
other events).  That will allow us to inform users when they use
options incompatible with the event they selected.

For now, we make this a deprecation so that in the future we can
enforce it and improve feedback.

This adds syntax validation for each of the possible event/action
combinations in the case where the user has already specified a single
event.  This allows us to go ahead and issue warnings if users specify
incompatible options.  Later, all of these can become errors.

Some time ago (8.3.0) we deprecated the require-status attribute.  It
is eligible for removal now, but that predated the deprecation
warnings system.  Since we haven't yet removed it, and we now have
that system, let's add a deprecation warning for it and give users a
little more time to notice that and remove it before it becomes an
error.

When a Github user requests that a check run start again, Github emits
a "check_run" event with a "rerequested" action.  In zuul < 5.0.0, we
asked users to configure the check_run trigger with the "requested"
action and we silently translated the "rerequested" from github to the
zuul "requested".  In 5.0.0, we reversed that decision in order to
match our policy of passing through data from remote systems as
closely as possible to enable users to match the corresponding
documentation of zuul and the remote system.  We deprecated
"requested" and updated the examples in the documentation to say
"rerequested".  Unfortunately, we left the canonical documentation of
the value as "requested".  To correct this oversight, that
documentation is updated to say "rerequested" and a configuration
deprecation warning is added for uses of "requested".

The "unabel" trigger attribute is undocumented and unused.  Deprecate
it from syntax checking here so we can gracefully remove it later.

Some unit tests configs are updated since they passed validation
previously but no longer do, and the actual github pull request
review state constants ('approved', etc) are updated to match
what github sends.

Change-Id: I6bf7753d74ec0c5f19dad508c33762a7803fe805
2024-02-29 16:37:47 -08:00
James E. Blair 4421a87806 Add zuul_unreachable ansible host group
This will allow users to write post-run playbooks that skip
running certain tasks on unreachable hosts.

Change-Id: I04106ad0222bcd8073ed6655a8e4ed77f43881f8
2024-02-27 13:57:07 -08:00
Jeremy Stanley 6a58287812 2024 refresh of fungi's OpenPGP key expiration
I update the expiration on my key frequently and leave it set to no
more than one year, but as a result I forget to replace static
copies in various places. Do that again now.

Change-Id: I8879468679abc8ef2dd6b312daf35b71713f4fee
2024-02-21 13:30:04 +00:00
James E. Blair 8dd4011aa0 Monitor and report executor inode usage
This adds inodes to the hdd executor sensor and reports usage
to statsd as well.

Change-Id: Ifd9a63cfc7682f6679322e39809be69abca6827e
2024-02-19 11:20:57 -08:00
James E. Blair 5a8e373c3b Replace Ansible 6 with Ansible 9
Ansible 6 is EOL and Ansible 9 is available.  Remove 6 and add 9.

This is usually done in two changes, but this time it's in one
since we can just rotate the 6 around to make it a 9.

command.py has been updated for ansible 9.

Change-Id: I537667f66ba321d057b6637aa4885e48c8b96f04
2024-02-15 16:20:45 -08:00
Zuul 18a376e8e2 Merge "Refresh Keycloak OpenID Howto for latest Keycloak" 2024-02-14 21:36:17 +00:00
Jeremy Stanley 4f90164ba7 Refresh Keycloak OpenID Howto for latest Keycloak
Going back through the Howto, many of the Keycloak admin UI screens
have changed layout and prompts, making the guide less
straightforward to follow. Update it to match Keycloak 23 (latest at
time of writing).

It also appears that pyJWT 2.5.0 fixed the bug which caused it to
break on encountering unsupported keys, so the noted step for
disabling rsa-enc-generated should no longer be necessary (this has
also become somewhat harder to do in more recent Keycloak versions).

Newer Keycloak seems to get confused by trailing slashes on origins,
which causes problems for its CORS headers, so fix it and add a
parenthetical note as a reminder.

Change-Id: I585439d4718fafd7075a3ed31ebcd10139dc355a
2024-02-14 17:05:41 +00:00
Jeremy Stanley c940e122bc Test with Keycloak 23
The current Keycloak version is 23, represented by a moving 23.0 tag
on Quay. Run the Zuul integration with this version since it's
probably closer to what organizations are likely to deploy these
days (it's what the OpenDev Collaboratory is currently upgrading
their deployment to).

Drop the database vendor override to H2, since it's the default in
these newer Quarkus-based images anyway (and the envvar which was
used to set this in the older Wildfly-based images is ignored as
best I can tell, so it really was doing nothing).

Change-Id: Ifb0b085bb3702e52db8b382c28e1580643e3c33c
2024-02-12 23:51:43 +00:00
Zuul 1beac435ab Merge "Finish circular dependency refactor" 2024-02-10 21:27:22 +00:00
James E. Blair 1f026bd49c Finish circular dependency refactor
This change completes the circular dependency refactor.

The principal change is that queue items may now include
more than one change simultaneously in the case of circular
dependencies.

In dependent pipelines, the two-phase reporting process is
simplified because it happens during processing of a single
item.

In independent pipelines, non-live items are still used for
linear depnedencies, but multi-change items are used for
circular dependencies.

Previously changes were enqueued recursively and then
bundles were made out of the resulting items.  Since we now
need to enqueue entire cycles in one queue item, the
dependency graph generation is performed at the start of
enqueing the first change in a cycle.

Some tests exercise situations where Zuul is processing
events for old patchsets of changes.  The new change query
sequence mentioned in the previous paragraph necessitates
more accurate information about out-of-date patchsets than
the previous sequence, therefore the Gerrit driver has been
updated to query and return more data about non-current
patchsets.

This change is not backwards compatible with the existing
ZK schema, and will require Zuul systems delete all pipeline
states during the upgrade.  A later change will implement
a helper command for this.

All backwards compatability handling for the last several
model_api versions which were added to prepare for this
upgrade have been removed.  In general, all model data
structures involving frozen jobs are now indexed by the
frozen job's uuid and no longer include the job name since
a job name no longer uniquely identifies a job in a buildset
(either the uuid or the (job name, change) tuple must be
used to identify it).

Job deduplication is simplified and now only needs to
consider jobs within the same buildset.

The fake github driver had a bug (fakegithub.py line 694) where
it did not correctly increment the check run counter, so our
tests that verified that we closed out obsolete check runs
when re-enqueing were not valid.  This has been corrected, and
in doing so, has necessitated some changes around quiet dequeing
when we re-enqueue a change.

The reporting in several drivers has been updated to support
reporting information about multiple changes in a queue item.

Change-Id: I0b9e4d3f9936b1e66a08142fc36866269dc287f1
Depends-On: https://review.opendev.org/907627
2024-02-09 07:39:40 -08:00
James E. Blair 754e03d9e0 Use exec in tutorial docker-compose files
In the tutorial docker-compose files, we override the zuul container
commands to run a shell script to wait for certs before starting
Zuul.  When `podman-compose down` runs `podman -t 10 stop`, it sends a
signal to dumb-init which sends a signal to the shell we configured
as well as to the zuul process.  The zuul process starts to shutdown
but the shell kills it before it finishes.

If the process exits before releasing the ssh stream event election,
then the quick-start job runs one of the follow-on tutorials which
restart the scheduler, then the scheduler will wait for the election
timeout of 30 seconds before it starts receiving events.  If the
tutorial playbook has proceeded to emit an event (eg "recheck"), then
the event will be missed and the job fail.

To correct this, exec the zuul processes after our shell script is
done so that only zuul receives the kill signal and handles it
completely.  Same for zk on general principle.

Change-Id: I90edbc68712bbd92ad1ac98b5960347de29b5342
2024-02-06 13:49:45 -08:00
Zuul 7f64f778da Merge "gitlab doc - update the reference pipelines" 2024-01-24 18:43:23 +00:00
Fabien Boucher 8c9c969993 gitlab doc - update the reference pipelines
This change simplify the Gitlab reference pipeline to avoid the clean check
and make it more similar to the Gerrit reference pipeline.

Furthermore and it is the main motivation behind that change is that,
is case of merge failures (for whatever reason) and if gate job succeeded,
then the approval is set and this generates a gate trigger event. This
makes Zuul to re-run the gate pipeline and try to merge again. This
can loop as long as the merge action fails.

Change-Id: I4c22e562797505d8ebdceb75180c537787cc3cb8
2024-01-24 10:34:15 +00:00
Zuul dbaf0b49a4 Merge "Re-elect James Blair as project lead" 2024-01-20 17:28:16 +00:00
Zuul 7aa36b2709 Merge "Include job_uuid in BuildRequests/Events" 2024-01-13 21:21:14 +00:00
Zuul 87cdd50752 Merge "Include job_uuid in NodeRequests" 2024-01-13 21:21:12 +00:00
Zuul 8d149846f3 Merge "Store builds on buildset by uuid" 2024-01-13 21:21:10 +00:00
Zuul 0ffe18a930 Merge "Index job map by uuid" 2024-01-13 17:27:33 +00:00
James E. Blair 663931cba3 Include job_uuid in BuildRequests/Events
This is part of the circular dependency refactor.

It updates BuildRequests to include the job uuid (similar to the
previous change with NodeRequests).  We also use the job uuid when
sending BuildResultEvents.

Change-Id: If7a55138d0cb5a358c62e8cd97ee322087b09a6b
2024-01-08 08:54:56 -08:00
James E. Blair 4f724fb22e Re-elect James Blair as project lead
Extend my term as project lead for another year.

Change-Id: I6f625be5da1e516f105a24f4bbaae3bf0c51f7ff
2024-01-08 07:30:13 -08:00
James E. Blair 7262ef7f6f Include job_uuid in NodeRequests
This is part of the circular dependency refactor.  It updates the
NodeRequest object to include the job_uuid in addition to the job_name
(which is temporarily kept for backwards compatability).  When node
requests are completed, we now look up the job by uuid if supplied.

Change-Id: I57d4ab6c241b03f76f80346b5567600e1692947a
2023-12-20 10:44:04 -08:00
Zuul 3c1eaab8cc Merge "Use a seeded PRNG when setting timer triggers" 2023-12-13 10:38:41 +00:00
James E. Blair be4ab1bb38 Use a seeded PRNG when setting timer triggers
In the single scheduler days, we went to some effort to make sure
that we preserved apscheduler timer trigger jobs across reconfigurations
because to do otherwise risks missing zuul triggers if we reconfigure
within the jitter interval of a timer job.

In other words, if a timer trigger is set for midnight with a jitter
of 60s, and we reconfigure the tenant at midnight plus 10 seconds, if
the jitter would have caused the trigger to fire at midnight plus 30
seconds and the apscheduler job is canceled and recreated but this
time the jitter would cause it to fire at midnight plus 5 seconds,
the job would not fire.

Our mitigation for this was to preserve the apscheduler jobs across
reconfigurations, assuming nothing has changed.

In the multi-scheduler world, a similar problem arises when we perform
a rolling restart during a jitter interval.  Fixing this by recording
all of the jobs in ZK would be costly (as we create an apscheduler job
for each project-branch participating in a timer pipeline).  But we
can address the bulk of the problem just by ensuring that the same
jitter values are used on all schedulers.  This reduces the window for
missed jobs down to the time it takes for the schedulers to run the
timer trigger election (which, assuming an orderly shutdown, is very
fast).

In APScheduler the jitter value is calculated for every event.  This
new approach calculates a fixed jitter for a job, and will use that
value every time the job fires.  So if a job ends up running at
midnight plus 10 seconds one day, and no configuration changes,
it will run at midnight plus 10 seconds the next day.  This is
sufficient to achieve what we want to do with jitter: avoid starting
all the jobs at once.

We subclass the apscheduler CronTrigger to implement this custom
fixed jitter behavior and use a PRNG seeded with the tenant, project
and branch so that each scheduler will use the same value for each
combination, assuming they have the same configuration (and they
should).

Docs are updated to highlight that the same jitter value may be reused,
but no release note is added since the behavior change is not
significant.

Change-Id: Idd9d3a8cfa791860e46e4fc508566417f5d5a9bf
2023-12-12 13:25:14 -08:00
James E. Blair 9201f9ee28 Store builds on buildset by uuid
This is part of the circular dependency refactor.

This updates the buildset object in memory (and zk) to store builds
indexed by frozen job uuid rather than job name.  This also updates
everal related fields and also temporary dictionaries to do the same.

This will allow us, in the future, to have more than one job/build
in a buildset with the same name (for different changes/refs).

Change-Id: I70865ec8d70fb9105633f0d03ba7c7e3e6cd147d
2023-12-12 11:58:21 -08:00
James E. Blair cb3c4883f2 Index job map by uuid
This is part of the circular dependency refactor.  It changes the
job map (a dictionary shared by the BuildSet and JobGraph classes
(BuildSet.jobs is JobGraph._job_map -- this is because JobGraph
is really just a class to encapsulate some logic for BuildSet))
to be indexed by FrozenJob.uuid instead of job name.  This helps
prepare for supporting multiple jobs with the same name in a
buildset.

Change-Id: Ie17dcf2dd0d086bd18bb3471592e32dcbb8b8bda
2023-12-12 10:22:25 -08:00
Zuul 4fb47d40d3 Merge "Add gerrit hashtags support" 2023-12-07 22:15:27 +00:00
James E. Blair 164b1784c6 Add gerrit hashtags support
This adds support for the hashtags-changed trigger event as well
as using hashtags as pipeline and trigger requirements.

Change-Id: I1f6628d7c227d12355f651c3c822b06e2d5c5562
2023-12-07 07:07:14 -08:00
James E. Blair 071c48c5ae Freeze job dependencies with job graph
This is part of the circular dependency refactor.

Update the job graph to record job dependencies when it is frozen,
and store these dependencies by uuid.  This means our dependency
graph points to actual frozen jobs rather than mere job names.

This is a pre-requisite to being able to disambiguate dependencies
later when a queue item supports multiple jobs with the same name.

The behavior where we would try to unwind an addition to the job
graph if it failed is removed.  This was originally written with the
idea that we would try to run as many jobs as possible if there was
a config error.  That was pre-zuul-v3 behavior.  Long since, in all
cases when we actually encounter an error adding to the job graph,
we bail and report that to the user.  No longer handling that
case simplifies the code somewhat and makes it more future-proof
(while complicating one of the tests that relied on that behavior
as a shortcut).

This attempts to handle upgrades by emulating the old behavior
if a job graph was created on an older model version.  Since it
relies on frozen job uuids, it also attempts to handle the case
where a frozenjob does not have a uuid (which is a very recent
model change and likely to end up in the same upgrade for some
users) by emulating the old behavior.

Change-Id: I0070a07fcb5af950651404fa8ae66ea18c6ca006
2023-12-06 16:41:18 -08:00
Simon Westphahl 68d7a99cee
Send job parent data + artifacts via build request
With job parents that supply data we might end up updating the (secret)
parent data and artifacts of a job multiple times in addition to also
storing duplicate data as most of this information is part of the
parent's build result.

Instead we will collect the parent data and artifacts before scheduling
a build request and send it as part of the request paramters.

If those parameters are part of the build request the executor will use
them, otherwise it falls back on using the data from the job for
backward compatibility.

This change affects the behavior of job deduplication in that input data
from parent jobs is no longer considered when deciding if a job can be
deduplicated or not.

Change-Id: Ic4a85a57983d38f033cf63947a3b276c1ecc70dc
2023-11-15 07:24:52 +01:00
Simon Westphahl 93b4f71d8e
Store frozen jobs using UUID instead of name
Change the frozen job storage in ZK from being identified by name to
UUID. This allows us to handle multiple frozen jobs in a buildset with
the same name.

The job graph will get a new field that is a sorted list of job UUIDs
with the index being the same as for the job name list. Jobs that are
created with the old name-based path will have their UUID set to None.

This is done in preparation of the circular dependency refactoring as
detailed in I8c754689ef73ae20fd97ac34ffc75c983d4797b0.

Change-Id: Ic4df16e8e1ec6908234ecdf91fe08408182d05bb
2023-11-10 07:24:35 +01:00
Zuul d781291dbf Merge "Select correct merge method for Github" 2023-10-24 15:52:37 +00:00
Simon Westphahl 810191b60e
Select correct merge method for Github
Starting with Github Enterprise 3.8[0] and github.com from September
2022 on[1], the merge strategy changed from using merge-recursive to
merge-ort[0].

The merge-ort strategy is available in the Git client since version
2.33.0 and became the default in 2.34.0[2].

If not configured otherwise, we've so far used the default merge
strategy of the Git client (which varies depending on the client
version). With this change, we are now explicitly choosing the default
merge strategy based on the Github version. This way, we can reduce
errors resulting from the use of different merge strategies in Zuul and
Github.

Since the newly added merge strategies must be understood by the mergers
we also need to bump the model API version.

[0] https://docs.github.com/en/enterprise-server@3.8/admin/release-notes
[1] https://github.blog/changelog/2022-09-12-merge-commits-now-created-using-the-merge-ort-strategy/
[2] https://git-scm.com/docs/merge-strategies#Documentation/merge-strategies.txt-recursive

Change-Id: I354a76fa8985426312344818320980c67171d774
2023-10-24 07:15:39 +02:00
Zuul 17badd55a6 Merge "Add spec for refactoring circular dependencies" 2023-10-20 01:11:55 +00:00
Zuul bd11c4ff79 Merge "Add gcloud pubsub support to Gerrit driver" 2023-10-04 03:29:42 +00:00
James E. Blair 30d579f8da Add spec for refactoring circular dependencies
Change-Id: I8c754689ef73ae20fd97ac34ffc75c983d4797b0
2023-09-21 07:08:17 -07:00
Ian Wienand 3c2e518c52 github: fallback to api_token when can't find installation
graphql queries (I77be4f16cf7eb5c8035ce0312f792f4e8d4c3e10) require
authentication. Enqueueing changes from GitHub (including Depends-On)
requires we run a graphql query. This means that Zuul must be able to
authenticate either via an application or api_token to support features
like Depends-On.

If the app is setup (app_id in config) but we aren't installed with
permissions on the project we're looking up, then fall back to using a
specified api_token. This will make Depends-On work.

Logging is updated to reflect whether or not we are able to fallback to
the api_token if the application is not installed. We log the lack of an
application installation at info level if we can fallback to the token,
and log at error level if we're falling back to anonymous access.

For backward compatibility we continue to fallback to anonymous access
if neither an application install or api_token are present. The reason
for this is features like Job required-projects: work fine anonymously,
and there may be Zuul installations that don't need additional
functionality.

Keep in mind that authenticated requests to GitHub get larger API rate
limits. Zuul installations should consider setting an API token even
when using an application for this reason. This gives Zuul the best
chance that fallback requests will not be rate limited.

Documentation is updated, a changelog added and several test
configuration files are padded with the required info.

Story: #2008940
Change-Id: I2107aeafc55591eea790244701567569fa6e80d4
2023-09-18 09:29:38 -07:00
James E. Blair 70c34607f5 Add support for limiting dependency processing
To protect Zuul servers from accidental DoS attacks in case someone,
say, uploads a 1k change tree to gerrit, add an option to limit the
dependency processing in the Gerrit driver and in Zuul itself (since
those are the two places where we recursively process deps).

Change-Id: I568bd80bbc75284a8e63c2e414c5ac940fc1429a
2023-09-07 11:01:29 -07:00
James E. Blair 1d3013e68f Avoid sphinx 7.2.5
There is a bug currently being investigated, and it breaks us:
https://github.com/sphinx-doc/sphinx/issues/11662

Change-Id: Ic51903a86ae5b5c75e65741b94ff0889aa6b72d0
2023-08-31 08:55:59 -07:00
Zuul 90dce8ed12 Merge "Add pipeline queue stats" 2023-08-30 01:28:50 +00:00
Zuul 19d1e78f59 Merge "Add narrative documentation for pipeline window" 2023-08-30 01:28:46 +00:00