| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\ |
|
| | |
| |
| |
| | |
Change-Id: I1dfd557c9f39ccb3989dfa1c0ca148429bbbcbe0
|
| |\ \
| |/
|/| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Nodepool now exposes a slot attribute which is set by the static
and metastatic drivers to provide a stable id for which "slot"
is occupied by a node on a host with max-parallel-jobs > 1.
Expose this as a variable to Ansible so that jobs can use it
to provide stable but non-conflicting workspace paths.
This also documents all of the current "nodepool" host vars.
Change-Id: I07cea423df7811c1de7763ff48b8308768246810
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The event that's currently stored as part of the queue item is not
sharded. This means that we can see Zookeeper disconnects when the queue
item data exceeds the max. Znode size of 1MB.
Since we only need the event's timestamp and the Zuul event-id after an
item is enqueued, we can reduce the amount of data we store in Zookeeper
and also avoid sharding the event.
Change-Id: I13577498e55fd4bb189679836219dea4dc5729fc
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In order to better understand the scheduler run handler performance this
change adds a new `zuul.scheduler.run_handler` metric to measure the
duration of one run handler loop.
Change-Id: I77e862cf99d6a8445e71d7daab410d5853487dc3
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | | |
Change-Id: I072d81f6cfd489cf1cf69189eeb547e5cb68bebb
|
| | |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In I9628e2770dda120b269612e28bb6217036942b8e we switched zuul.change from
a plain string tagged with !unsafe to base64 encoded and no !unsafe tag.
The idea was to make the inventory file parseable by external tools while
avoiding accidental interpolation of the commit message by Ansible.
That doesn't work in all cases -- it's not hard to construct a scenario
where after base64 decoding the message any further processing by Ansible
causes it to undergo interpolation. Moreover, since then we have made
many changes to how we deal with variables; notably, the inventory.yaml
is no longer actually used by Zuul's Anisble -- it is now there only
for human and downstream processing. We call it the "debug inventory".
The actual inventory is much more complex and in some cases has lots of
!unsafe tags in it.
Given all that, it now seems like the most straightforward way to deal
with this is to tag the message variable as !unsafe when passing it to
Zuul's Ansible, but render it as plain text in the inventory.yaml.
To address backwards compatability, this is done in a new variable called
zuul.change_message. Since that's a more descriptive variable anyway,
we will just keep that one in the future and drop the current base64-
encoded zuul.message variable
Change-Id: Iea86de15e722bc271c1bf0540db2c9efb032500c
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This further reduces the number of ZK object reads during pipeline
refreshes by tracking when builds and frozen jobs are updated.
During the phases of a build where we know no updates can occur,
we already avoid refreshing the Build and FrozenJob objects.
But, for example, while a build is running we have to continually
refresh it to see if it has completed.
We can avoid this by recording expected version information in ZK
and only refresh those objects if we know our local copy is out
of date.
We can store the latest ZK object version of FrozenJob and Build
objects on the Buildset. On pipeline refresh, we currently
always refresh the buildset object, which means that when we
prepare to refresh the FrozenJob or Build objects underneath a
Buildset, we will have information about the latest versions of
those objects in ZK and can compare to the versions we currently
have in memory to decide if we need to refresh them. This should
reduce the number of reads in a pipeline refresh by about 50%.
But it will cause more writes, in that we will update the
Buildset object each time we modify one of its children. This
may affect pipeline processing times but the impact should be
very small.
We will use version numbers (rather than transaction ids) because they
are predictable, and updating the buildset first with the predicted
next version before updating the child avoids issues caused by a crash
between those two steps.
Since it is typical for many objects to be created at once, we do
optimize the case where the objects are initially created and we
avoid making an update to the BuildSet in that case so that we
don't repeatedly write the buildset object.
Change-Id: I3824af6149bf27c41a8d895fc682236bd0d91f6b
|
| |\ \ \ \ |
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | | |
Extend my term as project lead for another year.
Change-Id: I48b34551601236c99a2f2d0786cdde32d01d2c80
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Independent pipelines ignore requirements for non-live changes
because they are not actually executed. However, a user might
configure an independent pipeline that requires code review and
expect a positive code-review pipeline requirement to be enforced.
To ignore it risks executing unreviewed code via dependencies.
To correct this, we now enforce pipeline requirements in independent
pipelines in the same way as dependent ones.
This also adds a new "allow-other-connections" pipeline configuration
option which permits users to specify exhaustive pipeline requirements.
Change-Id: I6c006f9e63a888f83494e575455395bd534b955f
Story: 2010515
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This change documents the behavior of file matchers for refs that don't
contain any files.
This documents the behavior that was introduced with
Icf5df145e4cd351ffd04b1e417e9f7ab8c5ccd12 after the related discussion
in If7a3a7cc212c981529be086dadb8157f08bda342.
Change-Id: I579dd6b50cd50a78d5e846f7c2376ffc9e7ba4a1
|
| |\ \ \ \
| |/ / /
|/| | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This updates the branch cache (and associated connection mixin)
to include information about supported project merge modes. With
this, if a project on github has the "squash" merge mode disabled
and a Zuul user attempts to configure Zuul to use the "squash"
mode, then Zuul will report a configuration syntax error.
This change adds implementation support only to the github driver.
Other drivers may add support in the future.
For all other drivers, the branch cache mixin simply returns a value
indicating that all merge modes are supported, so there will be no
behavior change.
This is also the upgrade strategy: the branch cache uses a
defaultdict that reports all merge modes supported for any project
when it first loads the cache from ZK after an upgrade.
Change-Id: I3ed9a98dfc1ed63ac11025eb792c61c9a6414384
|
| |\ \ \ \ |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Gerrit 3.7 forbids setting the MaxWithBlock function on labels,
so replace that with these equivalent submit requirements in our
tutorial example configuration.
Change-Id: Iadca7d36a342eb1a890a7b83a5e08938a2b52e20
|
| |\ \ \ \ \
| |_|_|_|/
|/| | | | |
|
| | | |/ /
| |/| |
| | | |
| | | |
| | | |
| | | | |
This outlines our baseline assumptions regarding upgrading.
Change-Id: I2f63b3b3d643fc2aae4f35de8206d4081afa1494
|
| |\ \ \ \
| |_|/ /
|/| | | |
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
PyJWT 2.6.0 began performing validation of iat (issued at) claims
in https://github.com/jpadilla/pyjwt/commit/9cb9401cc579f11dbb17181e8713f061f8e40ed4
I believe the intent of RFC7519 is to support any numeric values
(including floating point) for iat, nbf, and exp, however, the
PyJWT library has made the assumption that the values should be
integers, and therefore when we supply an iat with decimal seconds,
PyJWT will round down when validating the value. In our unit tests,
this can cause validation errors.
In order to avoid any issues, we will round down the times that
we supply when generating JWT tokens and supply them as integers
in accordance with the robustness principle.
Change-Id: Ia8341b4d5de827e2df8878f11f2d1f52a1243cd4
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
docker.io/gerritcodereview/gerrit:latest has been updated to gerrit 3.7
it introduces breaking changes [1][2] that require to update how the
configuration is modified during tutorial run.
ERROR: ... Parameter 'label.Code-Review.copyMinScore'
is deprecated and cannot be set,
use 'is:MIN' in 'label.Code-Review.copyCondition' instead.
ERROR: ... Parameter 'label.Code-Review.copyAllScoresOnTrivialRebase'
is deprecated and cannot be set,
use 'changekind:TRIVIAL_REBASE' in 'label.Code-Review.copyCondition' instead.
ERROR: ... Value 'MaxWithBlock' of 'label.Verified.function'
is not allowed and cannot be set.
Label functions can only be set to {NO_BLOCK, NO_OP, PATCH_SET_LOCK}.
Use submit requirements instead of label functions.
[1] https://www.gerritcodereview.com/3.7.html#breaking-changes
[2] https://gerrit-review.googlesource.com/c/gerrit/+/334467
Change-Id: I2f27d0e99470c3baee82abc126cac72132a2da48
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This change is related to Id3669418189f1083a2fb690ada0b60043a77b1d6
and clarifies the zuul_console connectivity behaviour when dealing
with Kubernetes-based job nodes.
Change-Id: I7191631dc54071d158657816a8cc10335e122df5
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The zuul-from-scratch page was removed with
I3c6327c9bc1a924f076ded06afc0afc4e3024384, but all these files it
linked to were left behind.
At first glance this seemed a bit odd, because sphinx should warn when
pages aren't linked to from a TOC. It took me a while to realise
these pages were already marked with :orphan: at the top which stopped
this happening. So they really are orphans now, but we haven't
noticed.
This appears to go back well before the zuul-from-scratch removal to
some of the original organisation several years ago in
I206a2acf09eb8a2871ec61a00226654c798bb3eb -- it's not clear if this
flag was intended to be left in the files or was a temporary step; but
it seems that as we've gone on we've copied it into all the other
files as they got created too.
Most of this is all old and part of the bit-rot as described in the
original zuul-from-scratch removal. The only recent part is some
console streaming docs added with
I5bfb61323bf3219168d4d014cbb9703eed230e71 -- upon reevaluating this
I've moved it into the executor docs where it seems to fit.
The other orphaned files are removed.
Change-Id: Id3669418189f1083a2fb690ada0b60043a77b1d6
|
| |/
|
|
|
|
|
|
|
| |
This adds the ability to specify that the Zuul executor should
acquire a semaphore before running an individual playbook. This
is useful for long running jobs which need exclusive access to
a resources for only a small amount of time.
Change-Id: I90f5e0f570ef6c4b0986b0143318a78ddc27bbde
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
GitHub supports a "rebase" merge mode where it will rebase the PR
onto the target branch and fast-forward the target branch to the
result of the rebase.
Add support for this process to the merger so that it can prepare
an effective simulated repo, and map the merge-mode to the merge
operation in the reporter so that gating behavior matches.
This change also makes a few tweaks to the merger to improve
consistency (including renaming a variable ref->base), and corrects
some typos in the similar squash merge test methods.
Change-Id: I9db1d163bafda38204360648bb6781800d2a09b4
|
| |\ \
| |/ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The default merge mode is 'merge-resolve' because it has been observed
that it more closely matches the behavior of jgit in Gerrit (or, at
least it did the last time we looked into this). The other drivers
are unlikely to use jgit and more likely to use the default git
merge strategy.
This change allows the default to differ based on the driver, and
changes the default for all non-gerrit drivers to 'merge'.
The implementation anticipates that we may want to add more granularity
in the future, so the API accepts a project as an argument, and in
the future, drivers could provide a per-project default (which they
may obtain from the remote code review system). That is not implemented
yet.
This adds some extra data to the /projects endpoint in the REST api.
It is currently not easy (and perhaps not possible) to determine what a
project's merge mode is through the api. This change adds a metadata
field to the output which will show the resulting value computed from
all of the project stanzas. The project stanzas themselves may have
null values for the merge modes now, so the web app now protects against
that.
Change-Id: I9ddb79988ca08aba4662cd82124bd91e49fd053c
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This allows configuration of read-only access rules, and corresponding
documentation. It wraps every API method in an auth check (other than
info endpoints).
It exposes information in the info endpoints that the web UI can use
to decide whether it should send authentication information for all
requests. A later change will update the web UI to use that.
Change-Id: I3985c3d0b9f831fd004b2bb010ab621c00486e05
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In order to allow for authenticated read-only access to zuul-web,
we need to be able to control the authz of the API root. Currently,
we can only specify auth info for tenants. But if we want to control
access to the tenant list itself, we need to be able to specify auth
rules.
To that end, add a new "api-root" tenant configuration object which,
like tenants themselves, will allow attaching authz rules to it.
We don't have any admin-level API endpoints at the root, so this change
does not add "admin-rules" to the api-root object, but if we do develop
those in the future, it could be added.
A later change will add "access-rules" to the api-root in order to
allow configuration of authenticated read-only access.
This change does add an "authentication-realm" to the api-root object
since that already exists for tenants and it will make sense to have
that in the future as well. Currently the /info endpoint uses the
system default authentication realm, but this will override it if
set.
In general, the approach here is that the "api-root" object should
mirror the "tenant" object for all attributes that make sense.
Change-Id: I4efc6fbd64f266e7a10e101db3350837adce371f
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is a preparatory step to add access-control for read-level
access to the API and web UI. Because we will likely end up with
tenant config that looks like:
- tenant:
name: example
admin-rules: ['my-admin-rule']
access-rules: ['my-read-only-rule']
It does not make sense for 'my-read-only-rule' to be defined as:
- admin-rule:
name: read-only-rule
In other words, the current nomenclature conflates (new word:
nomenconflature) the idea of an abstract authorization rule and
what it authorizes. The new name makes it more clear than an
authorization-rule can be used to authorize more than just admin
access.
Change-Id: I44da8060a804bc789720bd207c34d802a52b6975
|
| |\ \ \ |
|
| | | |/
| |/|
| | |
| | | |
Change-Id: Icd8c33dfe1c8ffd21a717a1a94f1783c244a6b82
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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
|
| |/ /
| |
| |
| |
| |
| |
| |
| | |
This was introduced with I0273993c3ece4363098e4bf30bfc4308bb69a8b4.
The variable being checked is "zuul_console_disabled". Correct this
in the documentation.
Change-Id: Ib45ec943d4b227ba254354d116440aa521fb6b9e
|
| |\ \
| |/
|/| |
|
| | |
| |
| |
| |
| |
| | |
Old link is broken.
Change-Id: Ie7f476cfcc4dded2fb7418aefac0692132ca10d8
|
| | |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |\ \ |
|
| | | |
| | |
| | |
| | | |
Change-Id: I239c933c42b3298d85514055e49a586644972755
|
| |\ \ \ |
|
