| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|/ / / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Previously, metajobs set defaults for boolean attributes that were not
defined, and copied to them to matched jobs. This could result in a
metajob that did not define a voting attribute unintentially
overriding a matched job with the default voting value (True). This
change ensures that metajobs set values only for explicitly supplied
boolean attributes.
Change-Id: I99dc3a58c63946ddb54849b1629101b062159a69
Closes-Bug: #2000166
|
|\ \ \ \ |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Time has no meaning for non-live changes. Really only the time
for the live change at the end of the list has any relevance.
The enqueue time is just repeated, and the ETA of 0 is just weird.
Don't display them for non-live changes.
Change-Id: I93f0fc5bedb6c8bca7128c6a1d06a447248cb9d8
|
|\ \ \ \ \
| |/ / / / |
|
| |/ / /
| | | |
| | | |
| | | |
| | | |
| | | | |
Only count live changes on the status page.
Change-Id: I56c14bcdf0d5ef207b16781e82734c2c84113f50
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Sometimes, even after cloning a new repository, zuul will fail to
merge the change with a stack trace shown below.
I was using GitPython==0.3.2.1. Upgrading it to >= 0.3.3 resolves the issue.
2015-01-22 08:27:48,222 ERROR zuul.Merger: Exception while merging a change:
Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/zuul/merger/merger.py", line 234, in _mergeChange
commit = repo.merge(item['refspec'], 'resolve')
File "/usr/local/lib/python2.7/dist-packages/zuul/merger/merger.py", line 132, in merge
self.fetch(ref)
File "/usr/local/lib/python2.7/dist-packages/zuul/merger/merger.py", line 145, in fetch
origin.fetch(ref)
File "/usr/local/lib/python2.7/dist-packages/git/remote.py", line 598, in fetch
return self._get_fetch_info_from_stderr(proc, progress or RemoteProgress())
File "/usr/local/lib/python2.7/dist-packages/git/remote.py", line 540, in _get_fetch_info_from_stderr
for err_line, fetch_line in zip(fetch_info_lines, fetch_head_info))
File "/usr/local/lib/python2.7/dist-packages/git/remote.py", line 540, in <genexpr>
for err_line, fetch_line in zip(fetch_info_lines, fetch_head_info))
File "/usr/local/lib/python2.7/dist-packages/git/remote.py", line 252, in _from_line
raise ValueError("Failed to parse line: %r" % line)
ValueError: Failed to parse line: 'Total 7 (delta 0), reused 7 (delta 0)'
This is the more specific GitPython Commit that resolves the issue:
https://github.com/gitpython-developers/GitPython/commit/d48ed95cc7bd2ad0ac36593bb2440f24f675eb59
Closes-Bug: #2000130
Change-Id: I1992b492e8c80322cc6ae01f6e2ebc181a9de813
|
|\ \ \ \
| |/ / /
|/| | | |
|
| |/ /
| | |
| | |
| | |
| | |
| | | |
It's not used anymore.
Change-Id: Ie344fac126ccad610e43b5cda36d4be93e1dc82a
|
|\ \ \
| |_|/
|/| | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
There was previously no way to skip a job if the contents of a given
patchset did not require it to be run. This meant that tempest jobs
would run in response to patchsets that would not affect their
execution, like those that only modified documentation or unit tests.
This change introduces a 'skip-if' configuration option that allows
jobs to be configured to not run when specified criteria are met.
Change-Id: I9b261f03ec00426160d9396f3a20312e89b624d4
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Because information moves from merge_client.build_sets to
sched.result_event_queue, perform the merge_client check first
because that is less racy in case of a context switch between
the two checks.
Change-Id: I0c55ee5f04a404f5ab9e3095d2cfabb10a8f64e9
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
With the previous CRD changes in effect, the merge-check pipeline
became rather large since it needlessly stacked dependent (both
git-dependent and commit-dependent) changes for each change tested.
Since commit-dependencies should not affect whether a change has
a merge conflict, and git-dependencies are already taken care of,
add an option to allow independent pipelines to ignore dependencies.
We will only set this for the merge-check pipeline in OpenStack.
Change-Id: I553446374ac12aa3e3f2e4bbea7ca8fafba42294
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
On an independent pipeline manager, getChangeQueue dynamically
creates change queues (they are static on dependent pipelines).
It is possible that one might call getChangeQueue() and then
decide not to actually use the change queue which was created.
Rather than asking the programmer to remember to clean up in
that case, make the interface to getChangeQueue() a context
manager so that it is cleaned up automatically.
No existing code-path was found that needed this, but this seems
like a sensible precaution for the future.
Change-Id: Ia2805cdb4d882fafa2decaf00573f657f412d983
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The checks to remove old versions or abandoned changes have been
updated to operate on items and consider whether those items are
live.
Change-Id: Ife3c4833a7d6a8f29014eabb33e50f82918051f4
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If two git-dependent changes in the same project are added to an
independent pipeline, the first should be enqueued as a single
live item in its own change queue, and the second should be
enqueued as a live item behind a non-live copy of the first with
those two in their own change queue. However, the current
behavior is that they are enqueued as two live items each in
their own change queue.
Once the first is removed, the queue processor would determine
that a dependency of the second change had failed to merge, and
therefore the second failed tests (as if it were in a dependent
pipeline). This is because the queue processor looked for the
status of dependent changes throughout the pipeline, so any
failed dependent change would cause it to fail a change.
The queue processor now only looks ahead in a given item's change
queue (rather than the entire pipeline) to determine if a needed
change is missing.
Change-Id: Ieaa0cdbff59e6b77a11c82876f4fd5cb01fe950b
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Currently the job listing for changes in the status JSON as well
as the jobs that are checked for completion, and listed in the report
all come from a method that operates on changes, not items.
Alter it to operate on items so it can return the empty list for
non-live items. This is safe within the queue processor because of
the previous change that explicitly checks for non-live items when
determining whether changes are complete.
Include the liveness attribute in the status JSON.
Use a grey dot for non-live items in the status screen.
Change-Id: I8907108a2f8f43c75b9cabe86e7c519790d58027
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Currently, areAllJobsComplete(item) is always False for a non-live
item because jobs are never started. However, to make the logic
of the queue processor more explicit, and protect against a future
potential improvement where a non-live item has no jobs associated,
check for whether an item is live along with the rest of the criteria
for the step where an item is dequeued when complete.
Change-Id: I1685de0705bc0cffddc528e80bf4beeb20ad3803
|
|\ \ \ |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Test that when two changes (in different branches) share a change-id
that Zuul depends on both.
Test that when two change ids are listed in a commit, zuul depends
on both.
Test that reconfiguration with changes in the check queue still
produces the same non-live + live change pair in a shared queue.
Also update the change history assertion in some tests to verify
the 'project1-merge' job by name which is less racy than checking
the last job (which may vary).
Change-Id: Ib2b8202f24578b10aa706befcca40b85459e1b97
|
|\ \ \ \
| |/ / / |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Changes supplied by the Depends-On header in git commit messages
will now additionally pull in changes from any project, on any
branch into independent pipelines. They are considered "non-live"
changes, that is, changes that should not have any tests run on
them.
To accomodate this, the internal structure of an independent
pipeline is now a dynamically adjusting list of ChangeQueue objects
where a new ChangeQueue is created for each change added to the
pipeline (and that ChangeQueue might contain non-live changes
enqueued ahead of the change we are interested in for the purpose
of stacking commits in the associated Zuul refs). This actually
more closely matches the visual and intuitive understanding of
independent pipelines.
Change-Id: I8ba0bc0918263f297666a50c607bca4f87c903b8
|
|\ \ \ \
| |/ / / |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Parse commit messages for "Depends-On: <changeid>" and treat
matching changes as changes that the given change depends on.
This will treat any changes in any branch of any project as
such. If the projects share a dependent change queue, the
changes will be enqueued in order. If they do not share a
change queue in a dependent pipeline, then the latter one will
be unable to be enqueued until the change it depends on merges.
If the dependencies result in a cycle, Zuul will log the error
but otherwise the problematic changes will be ignored.
Dependent changes in independent pipelines are not yet addressed.
Change-Id: I90c173f86d11e6c44d1f408646589b7c75b1cd52
|
|\ \ \ \
| |/ / / |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
To fully validate that the logic in enqueueChangesAhead and
enqueueChangesBehind is working as intended, create a complex
graph of dependent changes and ensure that even when a change
in the middle is the triggering change, the whole graph is
enqueued in the correct order.
This also adds a missing return statement from the addChange
method. It does not actually alter the result in this case as
the current code has enough repitition in walking up and down
the tree to eventually enqueue everything, however, it might
be possible for it to produce the wrong result in some cases,
or perhaps do so in a less efficient way. At any rate, I
believe the added return value is more correct.
Also, this adjusts one of the most annoying log messages, where
a perfectly normal false condition was being logged at error
level.
Change-Id: Ie39f24943d878ae7510736250fb3c43c53649de0
|
|\ \ \ \
| |/ / / |
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Does not actually handle more than one change correctly yet.
Just turns the attribute into a list and makes current processing
iterative.
Change-Id: I1acd62125b315fdcf04594cb52a71b16093884a7
|
|\ \ \ |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Turns out that the shortcut --verified or --code-review only work when
these labels are defined globally for all projects [1]. The other syntax
with a --label works fine even when e.g. the Verified label is being
used just for a subset of projects.
[1] https://gerrit-review.googlesource.com/#/c/51800/1/Documentation/cmd-review.txt
Change-Id: Ib591997141b68708bee0b291bb88a93cd3294301
|
|\ \ \ \ |
|
| | |/ /
| |/| |
| | | |
| | | | |
Change-Id: I69f8bbd9d78abdebd212f2e74d46178f592fc916
|
|\ \ \ \ |
|
| | |_|/
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The Zuul server supports dumping stacktrace by sending a SIGUSR2 signal.
Move the signal registration before the fork of the Gearman embedded
server to make it support the same behavior.
Clarify the relevant documentation to mention the forked process that
supports the embedded Gearman server supports SIGUSR2. Additionally
mentioned the log bucket being used (zuul.stack_dump) which might help
fine tweaking of the logger configuration.
Change-Id: I274cc7aba0eee624aafd3b75de15d6e26bdc8d21
|
|\ \ \ \
| |_|/ /
|/| | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
bootstrap-responsive is no longer required.
Make sure we follow redirects when fetching deps
Change-Id: Ib1222fcb590def5c0147a53f046def86da745830
|
|/ / /
| | |
| | |
| | | |
Change-Id: Id8f1ab1dfbe98411b71f7a7558664c950b93893f
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The pep8 jobs aren't running in gate at the moment.
Fix up the pep8 issues and remove the tox filter that stopped it
from running.
Also ignore E129 (visually indented line with same indent as next
logical line) as we don't follow it.
Change-Id: I394708ba96797bbc6fcd951e6436a104be0a3746
|
|\ \ \
| |/ /
|/| | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Periodic jobs currently trigger without a ZUUL_BRANCH or ZUUL_REF
variable set. (We should change this, but that's a more complex
change).
So that the cloner can be used in this situation, set those to
the empty string if their value is None (ie, unset).
Periodoc jobs can then invoke the cloner as normal, with branch
override values set, and those will be used as the selected
branch. This is how OpenStack's periodic branch jobs currently
work.
In the future, if Zuul itself performs branch selection on jobs,
this will provide a graceful migration path by allowing the
ZUUL_BRANCH values to act as a fallback and then the overrides
can be removed.
Add a test to validate this usage.
Change-Id: Ie680b9c11cebec7410ef7b0edc9d1017ae8b847e
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| | |
The latest release has a missing dependency.
Upstream bug:
https://alioth.debian.org/tracker/index.php?func=detail&aid=314945&group_id=100328&atid=413098
Partial-Bug: #2000107
Change-Id: Idf6ed3cb6ea34bee5252fb42ecdad1282e411409
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Add a test of the way that several zuul processes start using
the daemon and pidlockfile modules.
Ideally we would refactor this to use the actual code without
duplication, but recent releases of daemon are causing real problems
so suffer some duplication so that we can at least better evaluate
changes.
Change-Id: Ibaa0f481a52b6177dfffe1a58ebff342873df51b
|
|\ \ \
| |/ /
|/| | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
I got an exception that a list object has no method "get" when I
accidentally put the contents of my pipelines as the top level object in
the layout YAML file.
Change-Id: Ia88f2a849bbc1dca5ec44afc969ddfa9c3598f1e
|
|\ \ \ |
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If Gerrit is hosting also projects that are not using this
Zuul instance it is annoying to get warnings about
non-configured projects for each received Gerrit event.
Therefore the log level is being reduced to debug.
Change-Id: I535a4f4778c1413b6d30f81980769128bbaba6db
|
|\ \ \ |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Catches the GitCommandError exception when a ref does
not exist.
Change-Id: I9fe2e95d64eaf06537723957c6e7eaaf9282ccab
|
|\ \ \ \ |
|
| | |/ /
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
When layout_config points to a symbolic link, Zuul attempted to load the
python function from directory of the symbolic link instead of the
parent of the link target. That causes the scheduled to halt.
* Use realpath on layout_config path to make sure we will load from the
proper place.
* Update documentation of python-file to mention the include is relative
to the directory holding layout_config.
Change-Id: I33e221dd7c323423dbf781b53c06333dab2c7d29
|