zuul
/
zuul
Code Issues Proposed changes

docs: Fix spelling mistake 

Change-Id: I16dd017bf77dc7bf86138bb73a64ddc9786c1b57
This commit is contained in:
Zane Bitter 2021-05-17 12:07:06 -04:00
parent ddb7259f0d
commit 343f5f5583
2 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
doc/source/discussion/github-checks-api.rst
View File

@ -54,7 +54,7 @@ be selected as required status check. This is in conflict with
managing jobs in pipelines with Zuul. For example, to implement
branch protection on GitHub would mean listing each job as a dedicated
check, leading to a check run list that is not kept in sync with the
project's Zuul pipeline configuration. Additionally, you loose some
project's Zuul pipeline configuration. Additionally, you lose some
of Zuul's features like non-voting jobs as Github branch protections
has no concept of a non-voting job.

6
doc/source/reference/developer/specs/scale-out-scheduler.rst
View File

@ -16,7 +16,7 @@ can avoid this.
The same problem holds true when updating the scheduler. Currently there is no
possibility to upgrade the scheduler without downtime. While the pipeline state
can be saved and re-enqueued this still looses all in-flight jobs. Further on a
can be saved and re-enqueued this still loses all in-flight jobs. Further on a
larger deployment the startup of the scheduler easily can be in the multi minute
range. Having the ability to do zero downtime upgrades can make updates much
more easier.
@ -253,14 +253,14 @@ lifecycle will be as follows.
* If a build should be canceled the pipeline processor adds a ``cancel`` child
znode that will be recognized by the executor which will act accordingly.
It can be that an executor crashes. In this case it will loose the lock. We need
It can be that an executor crashes. In this case it will lose the lock. We need
to be able to recover from this and emit the right event to the pipeline.
Such a lost builds can be detected if it is in a state other than REQUESTED or
COMPLETED but unlocked. Any executor that sees such a request while looking for
new builds to execute will lock and mark it as COMPLETED and failed. It then
will emit a build completed event such that the pipeline event processor can
react on this and reschedule the build. There is no special handling needed to
return the nodes as in this case the failing executor will also loose its lock
return the nodes as in this case the failing executor will also lose its lock
on the nodes so they will be deleted or recycled by nodepool automatically.