Fix formatting of example blocks
With the new stylesheet example blocks (delimited with ====) are rendered as rather intrusive boxes with large padding in yellow and grey. This patch replaces the example blocks with simple code blocks (delimited with ----) that better match the overall style of the documentation. Change-Id: Id95387cdb153332c2066e2d5e378697647dbca52 Signed-off-by: Michael Ochmann <michael.ochmann@sap.com>
This commit is contained in:
Michael Ochmann
parent
402066405e
commit
b99feabd88
|
|
@ -421,10 +421,10 @@ draft patch sets of a change into public patch sets for review.
|
|||
To block push permission to `+refs/drafts/*+` the following permission rule can
|
||||
be configured:
|
||||
|
||||
====
|
||||
----
|
||||
[access "refs/drafts/*"]
|
||||
push = block group Anonymous Users
|
||||
====
|
||||
----
|
||||
|
||||
|
||||
[[access_categories]]
|
||||
|
|
@ -637,15 +637,15 @@ This category permits users to push an annotated tag object into the
|
|||
project's repository. Typically this would be done with a command line
|
||||
such as:
|
||||
|
||||
====
|
||||
----
|
||||
git push ssh://USER@HOST:PORT/PROJECT tag v1.0
|
||||
====
|
||||
----
|
||||
|
||||
Or:
|
||||
|
||||
====
|
||||
----
|
||||
git push https://HOST/PROJECT tag v1.0
|
||||
====
|
||||
----
|
||||
|
||||
Tags must be annotated (created with `git tag -a`), should exist in
|
||||
the `refs/tags/` namespace, and should be new.
|
||||
|
|
@ -677,15 +677,15 @@ This category permits users to push a PGP signed tag object into the
|
|||
project's repository. Typically this would be done with a command
|
||||
line such as:
|
||||
|
||||
====
|
||||
----
|
||||
git push ssh://USER@HOST:PORT/PROJECT tag v1.0
|
||||
====
|
||||
----
|
||||
|
||||
Or:
|
||||
|
||||
====
|
||||
----
|
||||
git push https://HOST/PROJECT tag v1.0
|
||||
====
|
||||
----
|
||||
|
||||
Tags must be signed (created with `git tag -s`), should exist in the
|
||||
`refs/tags/` namespace, and should be new.
|
||||
|
|
@ -1069,10 +1069,10 @@ It is also possible to block label ranges. To block a group 'X' from voting
|
|||
'-2' and '+2', but keep their existing voting permissions for the '-1..+1'
|
||||
range intact we would define:
|
||||
|
||||
====
|
||||
----
|
||||
[access "refs/heads/*"]
|
||||
label-Code-Review = block -2..+2 group X
|
||||
====
|
||||
----
|
||||
|
||||
The interpretation of the 'min..max' range in case of a blocking rule is: block
|
||||
every vote from '-INFINITE..min' and 'max..INFINITE'. For the example above it
|
||||
|
|
@ -1083,11 +1083,11 @@ means that the range '-1..+1' is not affected by this block.
|
|||
When an access section of a project contains a 'BLOCK' and an 'ALLOW' rule for
|
||||
the same permission then this 'ALLOW' rule overrides the 'BLOCK' rule:
|
||||
|
||||
====
|
||||
----
|
||||
[access "refs/heads/*"]
|
||||
push = block group X
|
||||
push = group Y
|
||||
====
|
||||
----
|
||||
|
||||
In this case a user which is a member of the group 'Y' will still be allowed to
|
||||
push to 'refs/heads/*' even if it is a member of the group 'X'.
|
||||
|
|
@ -1108,22 +1108,22 @@ This requirement is quite common in a corporate deployment where
|
|||
reproducibility of a build must be guaranteed. To achieve that we block 'push'
|
||||
permission for the <<anonymous_users,'Anonymous Users'>> in "`All-Projects`":
|
||||
|
||||
====
|
||||
----
|
||||
[access "refs/tags/*"]
|
||||
push = block group Anonymous Users
|
||||
====
|
||||
----
|
||||
|
||||
By blocking the <<anonymous_users,'Anonymous Users'>> we effectively block
|
||||
everyone as everyone is a member of that group. Note that the permission to
|
||||
create a tag is still necessary. Assuming that only <<category_owner,project
|
||||
owners>> are allowed to create tags, we would extend the example above:
|
||||
|
||||
====
|
||||
----
|
||||
[access "refs/tags/*"]
|
||||
push = block group Anonymous Users
|
||||
create = group Project Owners
|
||||
pushTag = group Project Owners
|
||||
====
|
||||
----
|
||||
|
||||
|
||||
==== Let only a dedicated group vote in a special category
|
||||
|
|
@ -1136,11 +1136,11 @@ this category. We have to block everyone except the 'Release Engineers' to vote
|
|||
in this category and, of course, allow 'Release Engineers' to vote in that
|
||||
category. In the "`All-Projects`" we define the following rules:
|
||||
|
||||
====
|
||||
----
|
||||
[access "refs/heads/stable*"]
|
||||
label-Release-Process = block -1..+1 group Anonymous Users
|
||||
label-Release-Process = -1..+1 group Release Engineers
|
||||
====
|
||||
----
|
||||
|
||||
[[global_capabilities]]
|
||||
== Global Capabilities
|
||||
|
|
|
|||
|
|
@ -44,10 +44,10 @@ This command is intended to be used in scripts.
|
|||
Ban commit `421919d015c062fd28901fe144a78a555d0b5984` from project
|
||||
`myproject`:
|
||||
|
||||
====
|
||||
----
|
||||
$ ssh -p 29418 review.example.com gerrit ban-commit myproject \
|
||||
421919d015c062fd28901fe144a78a555d0b5984
|
||||
====
|
||||
----
|
||||
|
||||
GERRIT
|
||||
------
|
||||
|
|
|
|||
|
|
@ -33,11 +33,11 @@ each commit message.
|
|||
To obtain the 'gerrit-cherry-pick' script use scp, curl or wget to
|
||||
copy it to your local system:
|
||||
|
||||
====
|
||||
----
|
||||
$ scp -p -P 29418 john.doe@review.example.com:bin/gerrit-cherry-pick ~/bin/
|
||||
|
||||
$ curl -Lo ~/bin/gerrit-cherry-pick http://review.example.com/tools/bin/gerrit-cherry-pick
|
||||
====
|
||||
----
|
||||
|
||||
GERRIT
|
||||
------
|
||||
|
|
|
|||
|
|
@ -68,9 +68,9 @@ This most likely requires double quoting the value, for example
|
|||
Create a new batch/role access user account called `watcher` in
|
||||
the 'Non-Interactive Users' group.
|
||||
|
||||
====
|
||||
----
|
||||
$ cat ~/.ssh/id_watcher.pub | ssh -p 29418 review.example.com gerrit create-account --group "'Non-Interactive Users'" --ssh-key - watcher
|
||||
====
|
||||
----
|
||||
|
||||
GERRIT
|
||||
------
|
||||
|
|
|
|||
|
|
@ -39,9 +39,9 @@ This command is intended to be used in scripts.
|
|||
Create a new branch called 'newbranch' from the 'master' branch of
|
||||
the project 'myproject'.
|
||||
|
||||
====
|
||||
----
|
||||
$ ssh -p 29418 review.example.com gerrit create-branch myproject newbranch master
|
||||
====
|
||||
----
|
||||
|
||||
GERRIT
|
||||
------
|
||||
|
|
|
|||
|
|
@ -67,16 +67,16 @@ to the group.
|
|||
Create a new account group called `gerritdev` with two initial members
|
||||
`developer1` and `developer2`. The group should be owned by itself:
|
||||
|
||||
====
|
||||
----
|
||||
$ ssh -p 29418 user@review.example.com gerrit create-group --member developer1 --member developer2 gerritdev
|
||||
====
|
||||
----
|
||||
|
||||
Create a new account group called `Foo` owned by the `Foo-admin` group.
|
||||
Put `developer1` as the initial member and include group description:
|
||||
|
||||
====
|
||||
----
|
||||
$ ssh -p 29418 user@review.example.com gerrit create-group --owner Foo-admin --member developer1 --description "'Foo description'" Foo
|
||||
====
|
||||
----
|
||||
|
||||
Note that it is necessary to quote the description twice. The local
|
||||
shell needs double quotes around the value to ensure the single quotes
|
||||
|
|
|
|||
|
|
@ -171,15 +171,15 @@ Common unit suffixes of 'k', 'm', or 'g' are supported.
|
|||
== EXAMPLES
|
||||
Create a new project called `tools/gerrit`:
|
||||
|
||||
====
|
||||
----
|
||||
$ ssh -p 29418 review.example.com gerrit create-project tools/gerrit.git
|
||||
====
|
||||
----
|
||||
|
||||
Create a new project with a description:
|
||||
|
||||
====
|
||||
----
|
||||
$ ssh -p 29418 review.example.com gerrit create-project tool.git --description "'Tools used by build system'"
|
||||
====
|
||||
----
|
||||
|
||||
Note that it is necessary to quote the description twice. The local
|
||||
shell needs double quotes around the value to ensure the single quotes
|
||||
|
|
@ -190,9 +190,9 @@ the single quotes to delimit the value.
|
|||
If the replication plugin is installed, the plugin will attempt to
|
||||
perform remote repository creation by a Bourne shell script:
|
||||
|
||||
====
|
||||
----
|
||||
mkdir -p '/base/project.git' && cd '/base/project.git' && git init --bare && git update-ref HEAD refs/heads/master
|
||||
====
|
||||
----
|
||||
|
||||
For this to work successfully the remote system must be able to run
|
||||
arbitrary shell scripts, and must have `git` in the user's PATH
|
||||
|
|
|
|||
|
|
@ -57,7 +57,7 @@ This command is intended to be used in scripts.
|
|||
== EXAMPLES
|
||||
List caches available for flushing:
|
||||
|
||||
====
|
||||
----
|
||||
$ ssh -p 29418 review.example.com gerrit flush-caches --list
|
||||
accounts
|
||||
accounts_byemail
|
||||
|
|
@ -68,32 +68,32 @@ List caches available for flushing:
|
|||
projects
|
||||
sshkeys
|
||||
web_sessions
|
||||
====
|
||||
----
|
||||
|
||||
Flush all caches known to the server, forcing them to recompute:
|
||||
|
||||
====
|
||||
----
|
||||
$ ssh -p 29418 review.example.com gerrit flush-caches --all
|
||||
====
|
||||
----
|
||||
|
||||
or
|
||||
|
||||
====
|
||||
----
|
||||
$ ssh -p 29418 review.example.com gerrit flush-caches
|
||||
====
|
||||
----
|
||||
|
||||
Flush only the "sshkeys" cache, after manually editing an SSH key
|
||||
for a user:
|
||||
|
||||
====
|
||||
----
|
||||
$ ssh -p 29418 review.example.com gerrit flush-caches --cache sshkeys
|
||||
====
|
||||
----
|
||||
|
||||
Flush "web_sessions", forcing all users to sign-in again:
|
||||
|
||||
====
|
||||
----
|
||||
$ ssh -p 29418 review.example.com gerrit flush-caches --cache web_sessions
|
||||
====
|
||||
----
|
||||
|
||||
== SEE ALSO
|
||||
|
||||
|
|
|
|||
|
|
@ -53,7 +53,7 @@ This command is intended to be used in scripts.
|
|||
|
||||
Run the Git garbage collection for the projects 'myProject' and
|
||||
'yourProject':
|
||||
=====
|
||||
----
|
||||
$ ssh -p 29418 review.example.com gerrit gc myProject yourProject
|
||||
collecting garbage for "myProject":
|
||||
...
|
||||
|
|
@ -62,12 +62,12 @@ Run the Git garbage collection for the projects 'myProject' and
|
|||
collecting garbage for "yourProject":
|
||||
...
|
||||
done.
|
||||
=====
|
||||
----
|
||||
|
||||
Run the Git garbage collection for all projects:
|
||||
=====
|
||||
----
|
||||
$ ssh -p 29418 review.example.com gerrit gc --all
|
||||
=====
|
||||
----
|
||||
|
||||
GERRIT
|
||||
------
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ JSON_SINGLE.
|
|||
== EXAMPLES
|
||||
To manually correct a user's SSH user name:
|
||||
|
||||
====
|
||||
----
|
||||
$ ssh -p 29418 review.example.com gerrit gsql
|
||||
Welcome to Gerrit Code Review v2.0.25
|
||||
(PostgreSQL 8.3.8)
|
||||
|
|
@ -54,7 +54,7 @@ To manually correct a user's SSH user name:
|
|||
Bye
|
||||
|
||||
$ ssh -p 29418 review.example.com gerrit flush-caches --cache sshkeys --cache accounts
|
||||
====
|
||||
----
|
||||
|
||||
GERRIT
|
||||
------
|
||||
|
|
|
|||
|
|
@ -63,26 +63,26 @@ it to your local system from your Gerrit server.
|
|||
|
||||
You can use either of the below commands:
|
||||
|
||||
====
|
||||
----
|
||||
$ scp -p -P 29418 <your username>@<your Gerrit review server>:hooks/commit-msg <local path to your git>/.git/hooks/
|
||||
|
||||
$ curl -Lo <local path to your git>/.git/hooks/commit-msg <your Gerrit http URL>/tools/hooks/commit-msg
|
||||
====
|
||||
----
|
||||
|
||||
A specific example of this might look something like this:
|
||||
|
||||
.Example
|
||||
====
|
||||
----
|
||||
$ scp -p -P 29418 john.doe@review.example.com:hooks/commit-msg ~/duhproject/.git/hooks/
|
||||
|
||||
$ curl -Lo ~/duhproject/.git/hooks/commit-msg http://review.example.com/tools/hooks/commit-msg
|
||||
====
|
||||
----
|
||||
|
||||
Make sure the hook file is executable:
|
||||
|
||||
====
|
||||
----
|
||||
$ chmod u+x ~/duhproject/.git/hooks/commit-msg
|
||||
====
|
||||
----
|
||||
|
||||
== SEE ALSO
|
||||
|
||||
|
|
|
|||
|
|
@ -29,9 +29,9 @@ This command is intended to be used in scripts.
|
|||
== EXAMPLES
|
||||
Index changes with legacy ID numbers 1 and 2.
|
||||
|
||||
====
|
||||
----
|
||||
$ ssh -p 29418 user@review.example.com gerrit index changes 1 2
|
||||
====
|
||||
----
|
||||
|
||||
GERRIT
|
||||
------
|
||||
|
|
|
|||
|
|
@ -7,11 +7,13 @@ from Gerrit's daemon, and then executed on the client system.
|
|||
|
||||
To download a client command or hook, use scp or an http client:
|
||||
|
||||
----
|
||||
$ scp -p -P 29418 john.doe@review.example.com:bin/gerrit-cherry-pick ~/bin/
|
||||
$ scp -p -P 29418 john.doe@review.example.com:hooks/commit-msg .git/hooks/
|
||||
|
||||
$ curl -Lo ~/bin/gerrit-cherry-pick http://review.example.com/tools/bin/gerrit-cherry-pick
|
||||
$ curl -Lo .git/hooks/commit-msg http://review.example.com/tools/hooks/commit-msg
|
||||
----
|
||||
|
||||
For more details on how to determine the correct SSH port number,
|
||||
see link:user-upload.html#test_ssh[Testing Your SSH Connection].
|
||||
|
|
@ -38,7 +40,9 @@ several other commands over its internal SSH daemon. As Gerrit does
|
|||
not provide an interactive shell, the commands must be triggered
|
||||
from an ssh client, for example:
|
||||
|
||||
----
|
||||
$ ssh -p 29418 review.example.com gerrit ls-projects
|
||||
----
|
||||
|
||||
For more details on how to determine the correct SSH port number,
|
||||
see link:user-upload.html#test_ssh[Testing Your SSH Connection].
|
||||
|
|
|
|||
|
|
@ -26,15 +26,15 @@ Caller must have the ADMINISTRATE_SERVER capability.
|
|||
== Examples
|
||||
|
||||
View the logging level of the loggers in the package com.google:
|
||||
=====
|
||||
----
|
||||
$ssh -p 29418 review.example.com gerrit logging ls-level \
|
||||
com.google.
|
||||
=====
|
||||
----
|
||||
|
||||
View the logging level of every logger
|
||||
=====
|
||||
----
|
||||
$ssh -p 29418 review.example.com gerrit logging ls-level
|
||||
=====
|
||||
----
|
||||
|
||||
GERRIT
|
||||
------
|
||||
|
|
|
|||
|
|
@ -33,16 +33,16 @@ Caller must have the ADMINISTRATE_SERVER capability.
|
|||
== Examples
|
||||
|
||||
Change the logging level of the loggers in the package com.google to DEBUG.
|
||||
=====
|
||||
----
|
||||
$ssh -p 29418 review.example.com gerrit logging set-level \
|
||||
debug com.google.
|
||||
=====
|
||||
----
|
||||
|
||||
Reset the logging level of every logger to what they were at deployment time.
|
||||
=====
|
||||
----
|
||||
$ssh -p 29418 review.example.com gerrit logging set-level \
|
||||
reset
|
||||
=====
|
||||
----
|
||||
|
||||
GERRIT
|
||||
------
|
||||
|
|
|
|||
|
|
@ -87,55 +87,55 @@ nonexistent group, the owner group name field will read `n/a`.
|
|||
== EXAMPLES
|
||||
|
||||
List visible groups:
|
||||
=====
|
||||
----
|
||||
$ ssh -p 29418 review.example.com gerrit ls-groups
|
||||
Administrators
|
||||
Anonymous Users
|
||||
MyProject_Committers
|
||||
Project Owners
|
||||
Registered Users
|
||||
=====
|
||||
----
|
||||
|
||||
List all groups for which any permission is set for the project
|
||||
"MyProject":
|
||||
=====
|
||||
----
|
||||
$ ssh -p 29418 review.example.com gerrit ls-groups --project MyProject
|
||||
MyProject_Committers
|
||||
Project Owners
|
||||
Registered Users
|
||||
=====
|
||||
----
|
||||
|
||||
List all groups which are owned by the calling user:
|
||||
=====
|
||||
----
|
||||
$ ssh -p 29418 review.example.com gerrit ls-groups --owned
|
||||
MyProject_Committers
|
||||
MyProject_Verifiers
|
||||
=====
|
||||
----
|
||||
|
||||
Check if the calling user owns the group `MyProject_Committers`. If
|
||||
`MyProject_Committers` is returned the calling user owns this group.
|
||||
If the result is empty, the calling user doesn't own the group.
|
||||
=====
|
||||
----
|
||||
$ ssh -p 29418 review.example.com gerrit ls-groups --owned -q MyProject_Committers
|
||||
MyProject_Committers
|
||||
=====
|
||||
----
|
||||
|
||||
Extract the UUID of the 'Administrators' group:
|
||||
|
||||
=====
|
||||
----
|
||||
$ ssh -p 29418 review.example.com gerrit ls-groups -v | awk '-F\t' '$1 == "Administrators" {print $2}'
|
||||
ad463411db3eec4e1efb0d73f55183c1db2fd82a
|
||||
=====
|
||||
----
|
||||
|
||||
Extract and expand the multi-line description of the 'Administrators'
|
||||
group:
|
||||
|
||||
=====
|
||||
----
|
||||
$ printf "$(ssh -p 29418 review.example.com gerrit ls-groups -v | awk '-F\t' '$1 == "Administrators" {print $3}')\n"
|
||||
This is a
|
||||
multi-line
|
||||
description.
|
||||
=====
|
||||
----
|
||||
|
||||
GERRIT
|
||||
------
|
||||
|
|
|
|||
|
|
@ -39,19 +39,19 @@ the output.
|
|||
== EXAMPLES
|
||||
|
||||
List members of the Administrators group:
|
||||
=====
|
||||
----
|
||||
$ ssh -p 29418 review.example.com gerrit ls-members Administrators
|
||||
id username full name email
|
||||
100000 jim Jim Bob somebody@example.com
|
||||
100001 johnny John Smith n/a
|
||||
100002 mrnoname n/a someoneelse@example.com
|
||||
=====
|
||||
----
|
||||
|
||||
List members of a non-existent group:
|
||||
=====
|
||||
----
|
||||
$ ssh -p 29418 review.example.com gerrit ls-members BadlySpelledGroup
|
||||
Group not found or not visible
|
||||
=====
|
||||
----
|
||||
|
||||
GERRIT
|
||||
------
|
||||
|
|
|
|||
|
|
@ -114,7 +114,7 @@ by the client in the request headers.
|
|||
== EXAMPLES
|
||||
|
||||
List visible projects:
|
||||
=====
|
||||
----
|
||||
$ ssh -p 29418 review.example.com gerrit ls-projects
|
||||
platform/manifest
|
||||
tools/gerrit
|
||||
|
|
@ -128,16 +128,16 @@ List visible projects:
|
|||
$ curl http://review.example.com/projects/tools/
|
||||
tools/gerrit
|
||||
tools/gwtorm
|
||||
=====
|
||||
----
|
||||
|
||||
Clone any project visible to the user:
|
||||
====
|
||||
----
|
||||
for p in `ssh -p 29418 review.example.com gerrit ls-projects`
|
||||
do
|
||||
mkdir -p `dirname "$p"`
|
||||
git clone --bare "ssh://review.example.com:29418/$p.git" "$p.git"
|
||||
done
|
||||
====
|
||||
----
|
||||
|
||||
== SEE ALSO
|
||||
|
||||
|
|
|
|||
|
|
@ -41,9 +41,9 @@ Administrators
|
|||
== EXAMPLES
|
||||
|
||||
List visible refs for the user "mr.developer" in project "gerrit"
|
||||
=====
|
||||
----
|
||||
$ ssh -p 29418 review.example.com gerrit ls-user-refs -p gerrit -u mr.developer
|
||||
=====
|
||||
----
|
||||
|
||||
GERRIT
|
||||
------
|
||||
|
|
|
|||
|
|
@ -31,9 +31,9 @@ This command is intended to be used in scripts.
|
|||
== EXAMPLES
|
||||
Enable a plugin:
|
||||
|
||||
====
|
||||
----
|
||||
ssh -p 29418 localhost gerrit plugin enable my-plugin
|
||||
====
|
||||
----
|
||||
|
||||
GERRIT
|
||||
------
|
||||
|
|
|
|||
|
|
@ -45,31 +45,31 @@ This command is intended to be used in scripts.
|
|||
== EXAMPLES
|
||||
Install a plugin from an absolute file path on the server's host:
|
||||
|
||||
====
|
||||
----
|
||||
ssh -p 29418 localhost gerrit plugin install -n name.jar \
|
||||
$(pwd)/my-plugin.jar
|
||||
====
|
||||
----
|
||||
|
||||
Install a WebUi plugin from an absolute file path on the server's host:
|
||||
|
||||
====
|
||||
----
|
||||
ssh -p 29418 localhost gerrit plugin install -n name.js \
|
||||
$(pwd)/my-webui-plugin.js
|
||||
====
|
||||
----
|
||||
|
||||
Install a plugin from an HTTP site:
|
||||
|
||||
====
|
||||
----
|
||||
ssh -p 29418 localhost gerrit plugin install -n name.jar \
|
||||
http://build-server/output/our-plugin
|
||||
====
|
||||
----
|
||||
|
||||
Install a plugin from piped input:
|
||||
|
||||
====
|
||||
----
|
||||
ssh -p 29418 localhost gerrit plugin install -n name.jar \
|
||||
- <target/name-0.1.jar
|
||||
====
|
||||
----
|
||||
|
||||
GERRIT
|
||||
------
|
||||
|
|
|
|||
|
|
@ -35,9 +35,9 @@ This command is intended to be used in scripts.
|
|||
== EXAMPLES
|
||||
Reload a plugin:
|
||||
|
||||
====
|
||||
----
|
||||
ssh -p 29418 localhost gerrit plugin reload my-plugin
|
||||
====
|
||||
----
|
||||
|
||||
GERRIT
|
||||
------
|
||||
|
|
|
|||
|
|
@ -32,9 +32,9 @@ This command is intended to be used in scripts.
|
|||
== EXAMPLES
|
||||
Disable a plugin:
|
||||
|
||||
====
|
||||
----
|
||||
ssh -p 29418 localhost gerrit plugin remove my-plugin
|
||||
====
|
||||
----
|
||||
|
||||
GERRIT
|
||||
------
|
||||
|
|
|
|||
|
|
@ -116,20 +116,20 @@ This command is intended to be used in scripts.
|
|||
== EXAMPLES
|
||||
|
||||
Find the 2 most recent open changes in the tools/gerrit project:
|
||||
====
|
||||
----
|
||||
$ ssh -p 29418 review.example.com gerrit query --format=JSON status:open project:tools/gerrit limit:2
|
||||
{"project":"tools/gerrit", ...}
|
||||
{"project":"tools/gerrit", ...}
|
||||
{"type":"stats","rowCount":2,"runningTimeMilliseconds:15}
|
||||
====
|
||||
----
|
||||
|
||||
Skip number of changes:
|
||||
====
|
||||
----
|
||||
$ ssh -p 29418 review.example.com gerrit query --format=JSON --start 42 status:open project:tools/gerrit limit:2
|
||||
{"project":"tools/gerrit", ...}
|
||||
{"project":"tools/gerrit", ...}
|
||||
{"type":"stats","rowCount":1,"runningTimeMilliseconds:15}
|
||||
====
|
||||
----
|
||||
|
||||
|
||||
== SCHEMA
|
||||
|
|
|
|||
|
|
@ -42,25 +42,25 @@ Any user who has configured an SSH key.
|
|||
== EXAMPLES
|
||||
|
||||
Send a review for a change on the master branch to charlie@example.com:
|
||||
=====
|
||||
----
|
||||
git push ssh://review.example.com:29418/project HEAD:refs/for/master%r=charlie@example.com
|
||||
=====
|
||||
----
|
||||
|
||||
Send reviews, but tagging them with the topic name 'bug42':
|
||||
=====
|
||||
----
|
||||
git push ssh://review.example.com:29418/project HEAD:refs/for/master%r=charlie@example.com,topic=bug42
|
||||
=====
|
||||
----
|
||||
|
||||
Also CC two other parties:
|
||||
=====
|
||||
----
|
||||
git push ssh://review.example.com:29418/project HEAD:refs/for/master%r=charlie@example.com,cc=alice@example.com,cc=bob@example.com
|
||||
=====
|
||||
----
|
||||
|
||||
Configure a push macro to perform the last action:
|
||||
====
|
||||
----
|
||||
git config remote.charlie.url ssh://review.example.com:29418/project
|
||||
git config remote.charlie.push HEAD:refs/for/master%r=charlie@example.com,cc=alice@example.com,cc=bob@example.com
|
||||
====
|
||||
----
|
||||
|
||||
afterwards `.git/config` contains the following:
|
||||
----
|
||||
|
|
@ -71,9 +71,9 @@ afterwards `.git/config` contains the following:
|
|||
|
||||
and now sending a new change for review to charlie, CC'ing both
|
||||
alice and bob is much easier:
|
||||
====
|
||||
----
|
||||
git push charlie
|
||||
====
|
||||
----
|
||||
|
||||
== SEE ALSO
|
||||
|
||||
|
|
|
|||
|
|
@ -31,9 +31,9 @@ This command is intended to be used in scripts.
|
|||
== EXAMPLES
|
||||
Rename the group "MyGroup" to "MyCommitters".
|
||||
|
||||
====
|
||||
----
|
||||
$ ssh -p 29418 user@review.example.com gerrit rename-group MyGroup MyCommitters
|
||||
====
|
||||
----
|
||||
|
||||
GERRIT
|
||||
------
|
||||
|
|
|
|||
|
|
@ -153,37 +153,37 @@ This command is intended to be used in scripts.
|
|||
== EXAMPLES
|
||||
|
||||
Approve the change with commit c0ff33 as "Verified +1"
|
||||
=====
|
||||
----
|
||||
$ ssh -p 29418 review.example.com gerrit review --verified +1 c0ff33
|
||||
=====
|
||||
----
|
||||
|
||||
Vote on the project specific label "mylabel":
|
||||
=====
|
||||
----
|
||||
$ ssh -p 29418 review.example.com gerrit review --label mylabel=+1 c0ff33
|
||||
=====
|
||||
----
|
||||
|
||||
Append the message "Build Successful". Notice two levels of quoting is
|
||||
required, one for the local shell, and another for the argument parser
|
||||
inside the Gerrit server:
|
||||
=====
|
||||
----
|
||||
$ ssh -p 29418 review.example.com gerrit review -m '"Build Successful"' c0ff33
|
||||
=====
|
||||
----
|
||||
|
||||
Mark the unmerged commits both "Verified +1" and "Code-Review +2" and
|
||||
submit them for merging:
|
||||
====
|
||||
----
|
||||
$ ssh -p 29418 review.example.com gerrit review \
|
||||
--verified +1 \
|
||||
--code-review +2 \
|
||||
--submit \
|
||||
--project this/project \
|
||||
$(git rev-list origin/master..HEAD)
|
||||
====
|
||||
----
|
||||
|
||||
Abandon an active change:
|
||||
====
|
||||
----
|
||||
$ ssh -p 29418 review.example.com gerrit review --abandon c0ff33
|
||||
====
|
||||
----
|
||||
|
||||
== SEE ALSO
|
||||
|
||||
|
|
|
|||
|
|
@ -102,9 +102,9 @@ This most likely requires double quoting the value, for example
|
|||
== EXAMPLES
|
||||
Add an email and SSH key to `watcher`'s account:
|
||||
|
||||
====
|
||||
----
|
||||
$ cat ~/.ssh/id_watcher.pub | ssh -p 29418 review.example.com gerrit set-account --add-ssh-key - --add-email mail@example.com watcher
|
||||
====
|
||||
----
|
||||
|
||||
GERRIT
|
||||
------
|
||||
|
|
|
|||
|
|
@ -34,9 +34,9 @@ This command is intended to be used in scripts.
|
|||
== EXAMPLES
|
||||
Change HEAD of project `example` to `stable-2.11` branch:
|
||||
|
||||
====
|
||||
----
|
||||
$ ssh -p 29418 review.example.com gerrit set-head example --new-head stable-2.11
|
||||
====
|
||||
----
|
||||
|
||||
GERRIT
|
||||
------
|
||||
|
|
|
|||
|
|
@ -58,18 +58,18 @@ This command is intended to be used in scripts.
|
|||
|
||||
Add alice and bob, but remove eve from the groups my-committers and
|
||||
my-verifiers.
|
||||
=====
|
||||
----
|
||||
$ ssh -p 29418 review.example.com gerrit set-members \
|
||||
-a alice@example.com -a bob@example.com \
|
||||
-r eve@example.com my-committers my-verifiers
|
||||
=====
|
||||
----
|
||||
|
||||
Include the group my-friends into the group my-committers, but
|
||||
exclude the included group my-testers from the group my-committers.
|
||||
=====
|
||||
----
|
||||
$ ssh -p 29418 review.example.com gerrit set-members \
|
||||
-i my-friends -e my-testers my-committers
|
||||
=====
|
||||
----
|
||||
|
||||
GERRIT
|
||||
------
|
||||
|
|
|
|||
|
|
@ -46,16 +46,16 @@ This command is intended to be used in scripts.
|
|||
== EXAMPLES
|
||||
Configure `kernel/omap` to inherit permissions from `kernel/common`:
|
||||
|
||||
====
|
||||
----
|
||||
$ ssh -p 29418 review.example.com gerrit set-project-parent --parent kernel/common kernel/omap
|
||||
====
|
||||
----
|
||||
|
||||
Reparent all children of `myParent` to `myOtherParent`:
|
||||
|
||||
====
|
||||
----
|
||||
$ ssh -p 29418 review.example.com gerrit set-project-parent \
|
||||
--children-of myParent --parent myOtherParent
|
||||
====
|
||||
----
|
||||
|
||||
== SEE ALSO
|
||||
|
||||
|
|
|
|||
|
|
@ -103,10 +103,10 @@ Common unit suffixes of 'k', 'm', or 'g' are supported.
|
|||
Change project `example` to be hidden, require change id, don't use content merge
|
||||
and use 'merge if necessary' as merge strategy:
|
||||
|
||||
====
|
||||
----
|
||||
$ ssh -p 29418 review.example.com gerrit set-project example --submit-type MERGE_IF_NECESSARY\
|
||||
--change-id true --content-merge false --project-state HIDDEN
|
||||
====
|
||||
----
|
||||
|
||||
GERRIT
|
||||
------
|
||||
|
|
|
|||
|
|
@ -55,27 +55,27 @@ This command is intended to be used in scripts.
|
|||
== EXAMPLES
|
||||
|
||||
Add reviewers alice and bob, but remove eve from change Iac6b2ac2.
|
||||
=====
|
||||
----
|
||||
$ ssh -p 29418 review.example.com gerrit set-reviewers \
|
||||
-a alice@example.com -a bob@example.com \
|
||||
-r eve@example.com \
|
||||
Iac6b2ac2
|
||||
=====
|
||||
----
|
||||
|
||||
Add reviewer elvis to old-style change id 1935 specifying that the change is in project "graceland"
|
||||
=====
|
||||
----
|
||||
$ ssh -p 29418 review.example.com gerrit set-reviewers \
|
||||
--project graceland \
|
||||
-a elvis@example.com \
|
||||
1935
|
||||
=====
|
||||
----
|
||||
|
||||
Add all project owners as reviewers to change Iac6b2ac2.
|
||||
=====
|
||||
----
|
||||
$ ssh -p 29418 review.example.com gerrit set-reviewers \
|
||||
-a "'Project Owners'" \
|
||||
Iac6b2ac2
|
||||
=====
|
||||
----
|
||||
|
||||
GERRIT
|
||||
------
|
||||
|
|
|
|||
|
|
@ -51,7 +51,7 @@ Intended for interactive use only.
|
|||
|
||||
== EXAMPLES
|
||||
|
||||
====
|
||||
----
|
||||
$ ssh -p 29418 review.example.com gerrit show-caches
|
||||
Gerrit Code Review 2.9 now 11:14:13 CEST
|
||||
uptime 6 days 20 hrs
|
||||
|
|
@ -90,7 +90,7 @@ Intended for interactive use only.
|
|||
107 open files
|
||||
|
||||
Threads: 4 CPUs available, 371 threads
|
||||
====
|
||||
----
|
||||
|
||||
== SEE ALSO
|
||||
|
||||
|
|
|
|||
|
|
@ -62,22 +62,22 @@ Remote Host::
|
|||
== EXAMPLES
|
||||
|
||||
With reverse DNS lookup (default):
|
||||
====
|
||||
----
|
||||
$ ssh -p 29418 review.example.com gerrit show-connections
|
||||
Session Start Idle User Remote Host
|
||||
--------------------------------------------------------------
|
||||
3abf31e6 20:09:02 00:00:00 jdoe jdoe-desktop.example.com
|
||||
--
|
||||
====
|
||||
----
|
||||
|
||||
Without reverse DNS lookup:
|
||||
====
|
||||
----
|
||||
$ ssh -p 29418 review.example.com gerrit show-connections -n
|
||||
Session Start Idle User Remote Host
|
||||
--------------------------------------------------------------
|
||||
3abf31e6 20:09:02 00:00:00 a/1001240 10.0.0.1
|
||||
--
|
||||
====
|
||||
----
|
||||
|
||||
GERRIT
|
||||
------
|
||||
|
|
|
|||
|
|
@ -70,7 +70,7 @@ The following queue contains two tasks scheduled to replicate the
|
|||
`tools/gerrit.git` project to two different remote systems, `dst1`
|
||||
and `dst2`:
|
||||
|
||||
====
|
||||
----
|
||||
$ ssh -p 29418 review.example.com gerrit show-queue
|
||||
Task State Command
|
||||
------------------------------------------------------------------------------
|
||||
|
|
@ -78,7 +78,7 @@ and `dst2`:
|
|||
9ad09d27 14:31:25.434 mirror dst2:/var/cache/tools/gerrit.git
|
||||
------------------------------------------------------------------------------
|
||||
2 tasks
|
||||
====
|
||||
----
|
||||
|
||||
GERRIT
|
||||
------
|
||||
|
|
|
|||
|
|
@ -37,18 +37,18 @@ This command is intended to be used in scripts.
|
|||
|
||||
== EXAMPLES
|
||||
|
||||
====
|
||||
----
|
||||
$ ssh -p 29418 review.example.com gerrit stream-events
|
||||
{"type":"comment-added",change:{"project":"tools/gerrit", ...}, ...}
|
||||
{"type":"comment-added",change:{"project":"tools/gerrit", ...}, ...}
|
||||
====
|
||||
----
|
||||
|
||||
Only subscribe to specific event types:
|
||||
|
||||
====
|
||||
----
|
||||
$ ssh -p 29418 review.example.com gerrit stream-events \
|
||||
-s draft-published -s patchset-created -s ref-replicated
|
||||
====
|
||||
----
|
||||
|
||||
== SCHEMA
|
||||
The JSON messages consist of nested objects referencing the *change*,
|
||||
|
|
|
|||
|
|
@ -48,7 +48,7 @@ This command is intended to be used in scripts.
|
|||
== EXAMPLES
|
||||
|
||||
Approve the change with commit c0ff33 as "Verified +1" as user bob@example.com
|
||||
=====
|
||||
----
|
||||
$ sudo -u gerrit ssh -p 29418 \
|
||||
-i site_path/etc/ssh_host_rsa_key \
|
||||
"Gerrit Code Review@localhost" \
|
||||
|
|
@ -56,7 +56,7 @@ Approve the change with commit c0ff33 as "Verified +1" as user bob@example.com
|
|||
--as bob@example.com \
|
||||
-- \
|
||||
gerrit approve --verified +1 c0ff33
|
||||
=====
|
||||
----
|
||||
|
||||
GERRIT
|
||||
------
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ Can be used by anyone that has permission to read the specified changeset.
|
|||
== EXAMPLES
|
||||
|
||||
Test submit_rule from stdin and return the results as JSON.
|
||||
====
|
||||
----
|
||||
cat rules.pl | ssh -p 29418 review.example.com gerrit test-submit rule -s I78f2c6673db24e4e92ed32f604c960dc952437d9
|
||||
[
|
||||
{
|
||||
|
|
@ -38,10 +38,10 @@ Test submit_rule from stdin and return the results as JSON.
|
|||
}
|
||||
}
|
||||
]
|
||||
====
|
||||
----
|
||||
|
||||
Test the active submit_rule from the refs/meta/config branch, ignoring filters in the project parents.
|
||||
====
|
||||
----
|
||||
$ ssh -p 29418 review.example.com gerrit test-submit rule I78f2c6673db24e4e92ed32f604c960dc952437d9 --no-filters
|
||||
[
|
||||
{
|
||||
|
|
@ -52,7 +52,7 @@ Test the active submit_rule from the refs/meta/config branch, ignoring filters i
|
|||
}
|
||||
}
|
||||
]
|
||||
====
|
||||
----
|
||||
|
||||
== SCRIPTING
|
||||
Can be used either interactively for testing new prolog submit rules, or from a script to check the submit status of a change.
|
||||
|
|
|
|||
|
|
@ -28,16 +28,16 @@ Can be used by anyone that has permission to read the specified change.
|
|||
== EXAMPLES
|
||||
|
||||
Test submit_type from stdin and return the submit type.
|
||||
====
|
||||
----
|
||||
cat rules.pl | ssh -p 29418 review.example.com gerrit test-submit type -s I78f2c6673db24e4e92ed32f604c960dc952437d9
|
||||
"MERGE_IF_NECESSARY"
|
||||
====
|
||||
----
|
||||
|
||||
Test the active submit_type from the refs/meta/config branch, ignoring filters in the project parents.
|
||||
====
|
||||
----
|
||||
$ ssh -p 29418 review.example.com gerrit test-submit type I78f2c6673db24e4e92ed32f604c960dc952437d9 --no-filters
|
||||
"MERGE_IF_NECESSARY"
|
||||
====
|
||||
----
|
||||
|
||||
== SCRIPTING
|
||||
Can be used either interactively for testing new prolog submit type, or from a script to check the submit type of a change.
|
||||
|
|
|
|||
|
|
@ -33,10 +33,10 @@ This command is intended to be used in scripts.
|
|||
|
||||
== EXAMPLES
|
||||
|
||||
=====
|
||||
----
|
||||
$ ssh -p 29418 review.example.com gerrit version
|
||||
gerrit version 2.4.2
|
||||
=====
|
||||
----
|
||||
|
||||
GERRIT
|
||||
------
|
||||
|
|
|
|||
|
|
@ -12,27 +12,27 @@ permissions work.
|
|||
|
||||
To retrieve the `project.config` file, initialize a temporary Git
|
||||
repository to edit the configuration:
|
||||
====
|
||||
----
|
||||
mkdir cfg_dir
|
||||
cd cfg_dir
|
||||
git init
|
||||
====
|
||||
----
|
||||
|
||||
Download the existing configuration from Gerrit:
|
||||
====
|
||||
----
|
||||
git fetch ssh://localhost:29418/All-Projects refs/meta/config
|
||||
git checkout FETCH_HEAD
|
||||
====
|
||||
----
|
||||
|
||||
Contributor agreements are defined as contributor-agreement sections in
|
||||
`project.config`:
|
||||
====
|
||||
----
|
||||
[contributor-agreement "Individual"]
|
||||
description = If you are going to be contributing code on your own, this is the one you want. You can sign this one online.
|
||||
agreementUrl = static/cla_individual.html
|
||||
autoVerify = group CLA Accepted - Individual
|
||||
accepted = group CLA Accepted - Individual
|
||||
====
|
||||
----
|
||||
|
||||
Each `contributor-agreement` section within the `project.config` file must
|
||||
have a unique name. The section name will appear in the web UI.
|
||||
|
|
@ -41,10 +41,10 @@ If not already present, add the UUID of the groups used in the
|
|||
`autoVerify` and `accepted` variables in the groups file.
|
||||
|
||||
Commit the configuration change, and push it back:
|
||||
====
|
||||
----
|
||||
git commit -a -m "Add Individual contributor agreement"
|
||||
git push ssh://localhost:29418/All-Projects HEAD:refs/meta/config
|
||||
====
|
||||
----
|
||||
|
||||
[[contributor-agreement.name.description]]contributor-agreement.<name>.description::
|
||||
+
|
||||
|
|
|
|||
|
|
@ -16,10 +16,10 @@ installed CGI. This defaults to `/usr/lib/cgi-bin/gitweb.cgi`,
|
|||
which is a common installation path for the 'gitweb' package on
|
||||
Linux distributions.
|
||||
|
||||
====
|
||||
----
|
||||
git config --file $site_path/etc/gerrit.config gitweb.cgi /usr/lib/cgi-bin/gitweb.cgi
|
||||
git config --file $site_path/etc/gerrit.config --unset gitweb.url
|
||||
====
|
||||
----
|
||||
|
||||
Alternatively, if Gerrit is served behind reverse proxy, it can
|
||||
generate different URLs for gitweb's links (they need to be
|
||||
|
|
@ -27,10 +27,10 @@ rewritten to `<gerrit>/gitweb?args` on the web server). This allows
|
|||
for serving gitweb under a different URL than the Gerrit instance.
|
||||
To enable this feature, set both: `gitweb.cgi` and `gitweb.url`.
|
||||
|
||||
====
|
||||
----
|
||||
git config --file $site_path/etc/gerrit.config gitweb.cgi /usr/lib/cgi-bin/gitweb.cgi
|
||||
git config --file $site_path/etc/gerrit.config gitweb.url /pretty/path/to/gitweb
|
||||
====
|
||||
----
|
||||
|
||||
After updating `'$site_path'/etc/gerrit.config`, the Gerrit server must
|
||||
be restarted and clients must reload the host page to see the change.
|
||||
|
|
@ -76,15 +76,15 @@ provides configuration parameters for integration with gitweb.
|
|||
|
||||
On Ubuntu:
|
||||
|
||||
====
|
||||
sudo apt-get install gitweb
|
||||
====
|
||||
----
|
||||
$ sudo apt-get install gitweb
|
||||
----
|
||||
|
||||
With Yum:
|
||||
|
||||
====
|
||||
----
|
||||
$ yum install gitweb
|
||||
====
|
||||
----
|
||||
|
||||
===== Configure Gitweb
|
||||
|
||||
|
|
@ -124,16 +124,16 @@ $favicon = "git-favicon.png";
|
|||
|
||||
Link gitweb to `/var/www/gitweb`, check `/etc/gitweb.conf` if unsure of paths:
|
||||
|
||||
====
|
||||
----
|
||||
$ sudo ln -s /usr/share/gitweb /var/www/gitweb
|
||||
====
|
||||
----
|
||||
|
||||
Add the gitweb directory to the Apache configuration by creating a "gitweb"
|
||||
file inside the Apache conf.d directory:
|
||||
|
||||
====
|
||||
----
|
||||
$ touch /etc/apache/conf.d/gitweb
|
||||
====
|
||||
----
|
||||
|
||||
Add the following to /etc/apache/conf.d/gitweb:
|
||||
|
||||
|
|
@ -150,9 +150,9 @@ is.
|
|||
|
||||
===== Restart the Apache Web Server
|
||||
|
||||
====
|
||||
$ sudo /etc/init.d/apache2 restart
|
||||
====
|
||||
----
|
||||
$ sudo /etc/init.d/apache2 restart
|
||||
----
|
||||
|
||||
Now you should be able to view your repository projects online:
|
||||
|
||||
|
|
@ -182,9 +182,9 @@ is broken.. The link:http://groups.google.com/group/msysgit/browse_thread/thread
|
|||
verify by checking for perl modules. From an msys console, execute the
|
||||
following to check:
|
||||
|
||||
====
|
||||
----
|
||||
$ perl -mCGI -mEncode -mFcntl -mFile::Find -mFile::Basename -e ""
|
||||
====
|
||||
----
|
||||
|
||||
You may encounter the following exception:
|
||||
|
||||
|
|
|
|||
|
|
@ -90,13 +90,13 @@ expect to use the Verified label to vote on a change after running.
|
|||
Administrators can install the Verified label by adding the following
|
||||
text to `project.config`:
|
||||
|
||||
====
|
||||
----
|
||||
[label "Verified"]
|
||||
function = MaxWithBlock
|
||||
value = -1 Fails
|
||||
value = 0 No score
|
||||
value = +1 Verified
|
||||
====
|
||||
----
|
||||
|
||||
The range of values is:
|
||||
|
||||
|
|
@ -323,11 +323,11 @@ Label's applicable scope can be branch specific via configuration.
|
|||
E.g. create a label `Video-Qualify` on parent project and configure
|
||||
the `branch` as:
|
||||
|
||||
====
|
||||
----
|
||||
[label "Video-Qualify"]
|
||||
branch = refs/heads/video-1.0/*
|
||||
branch = refs/heads/video-1.1/Kino
|
||||
====
|
||||
----
|
||||
|
||||
Then *only* changes in above branch scope of parent project and child
|
||||
projects will be affected by `Video-Qualify`.
|
||||
|
|
@ -343,13 +343,13 @@ ignored if the label doesn't apply for that branch.
|
|||
To define a new 3-valued category that behaves exactly like `Verified`,
|
||||
but has different names/labels:
|
||||
|
||||
====
|
||||
----
|
||||
[label "Copyright-Check"]
|
||||
function = MaxWithBlock
|
||||
value = -1 Do not have copyright
|
||||
value = 0 No score
|
||||
value = +1 Copyright clear
|
||||
====
|
||||
----
|
||||
|
||||
The new column will appear at the end of the table, and `-1 Do not have
|
||||
copyright` will block submit, while `+1 Copyright clear` is required to
|
||||
|
|
@ -360,7 +360,7 @@ enable submit.
|
|||
This example attempts to describe how a label default value works with the
|
||||
user permissions. Assume the configuration below.
|
||||
|
||||
====
|
||||
----
|
||||
[access "refs/heads/*"]
|
||||
label-Snarky-Review = -3..+3 group Administrators
|
||||
label-Snarky-Review = -2..+2 group Project Owners
|
||||
|
|
@ -374,7 +374,7 @@ user permissions. Assume the configuration below.
|
|||
value = +2 Hmm, this is pretty nice
|
||||
value = +3 Ohh, hell yes!
|
||||
defaultValue = -3
|
||||
====
|
||||
----
|
||||
|
||||
Upon clicking the Reply button:
|
||||
|
||||
|
|
@ -386,7 +386,7 @@ Upon clicking the Reply button:
|
|||
|
||||
This example shows how a label can be configured to have a standard patch set lock.
|
||||
|
||||
====
|
||||
----
|
||||
[access "refs/heads/*"]
|
||||
label-Patch-Set-Lock = +0..+1 group Administrators
|
||||
[label "Patch-Set-Lock"]
|
||||
|
|
@ -394,7 +394,7 @@ This example shows how a label can be configured to have a standard patch set lo
|
|||
value = 0 Patch Set Unlocked
|
||||
value = +1 Patch Set Locked
|
||||
defaultValue = 0
|
||||
====
|
||||
----
|
||||
|
||||
GERRIT
|
||||
------
|
||||
|
|
|
|||
|
|
@ -10,9 +10,9 @@ By default a new Gerrit installation relies upon OpenID to perform
|
|||
user authentication services. To enable OpenID, the auth.type
|
||||
setting should be `OpenID`:
|
||||
|
||||
====
|
||||
----
|
||||
git config --file $site_path/etc/gerrit.config auth.type OpenID
|
||||
====
|
||||
----
|
||||
|
||||
As this is the default setting there is nothing required from the
|
||||
site administrator to make use of the OpenID authentication services.
|
||||
|
|
@ -24,9 +24,9 @@ buffer size parameter, due to very long header lines.
|
|||
Add the following to `$JETTY_HOME/etc/jetty.xml` under
|
||||
`org.mortbay.jetty.nio.SelectChannelConnector`:
|
||||
|
||||
====
|
||||
----
|
||||
<Set name="headerBufferSize">16384</Set>
|
||||
====
|
||||
----
|
||||
|
||||
In order to use permissions beyond those granted to the
|
||||
`Anonymous Users` and `Registered Users` groups, an account
|
||||
|
|
@ -44,9 +44,9 @@ will match any OpenID provider on the Internet:
|
|||
* `https://` -- trust all OpenID providers using the HTTPS protocol
|
||||
|
||||
To trust only Yahoo!:
|
||||
====
|
||||
----
|
||||
git config --file $site_path/etc/gerrit.config auth.trustedOpenID https://me.yahoo.com
|
||||
====
|
||||
----
|
||||
|
||||
=== Database Schema
|
||||
|
||||
|
|
@ -100,11 +100,11 @@ all requests have already been authenticated. The "Sign In" and
|
|||
|
||||
To enable this form of authentication:
|
||||
|
||||
====
|
||||
----
|
||||
git config --file $site_path/etc/gerrit.config auth.type HTTP
|
||||
git config --file $site_path/etc/gerrit.config --unset auth.httpHeader
|
||||
git config --file $site_path/etc/gerrit.config auth.emailFormat '{0}@example.com'
|
||||
====
|
||||
----
|
||||
|
||||
The auth.type must always be HTTP, indicating the user identity
|
||||
will be obtained from the HTTP authorization data.
|
||||
|
|
@ -124,14 +124,14 @@ Apache server will be handling user authentication, a configuration
|
|||
such as the following is recommended to ensure Apache performs the
|
||||
authentication at the proper time:
|
||||
|
||||
====
|
||||
----
|
||||
<Location "/login/">
|
||||
AuthType Basic
|
||||
AuthName "Gerrit Code Review"
|
||||
Require valid-user
|
||||
...
|
||||
</Location>
|
||||
====
|
||||
----
|
||||
|
||||
=== Database Schema
|
||||
|
||||
|
|
@ -161,11 +161,11 @@ all requests have already been authenticated. The "Sign In" and
|
|||
|
||||
To enable this form of authentication:
|
||||
|
||||
====
|
||||
----
|
||||
git config --file $site_path/etc/gerrit.config auth.type HTTP
|
||||
git config --file $site_path/etc/gerrit.config auth.httpHeader SM_USER
|
||||
git config --file $site_path/etc/gerrit.config auth.emailFormat '{0}@example.com'
|
||||
====
|
||||
----
|
||||
|
||||
The auth.type must always be HTTP, indicating the user identity
|
||||
will be obtained from the HTTP authorization data.
|
||||
|
|
@ -186,9 +186,9 @@ buffer size parameter, due to very long header lines.
|
|||
Add the following to `$JETTY_HOME/etc/jetty.xml` under
|
||||
`org.mortbay.jetty.nio.SelectChannelConnector`:
|
||||
|
||||
====
|
||||
----
|
||||
<Set name="headerBufferSize">16384</Set>
|
||||
====
|
||||
----
|
||||
|
||||
|
||||
=== Database Schema
|
||||
|
|
|
|||
|
|
@ -88,7 +88,7 @@ reference the new image path.
|
|||
To connect Gerrit to Google Analytics add the following to your
|
||||
`GerritSiteFooter.html`:
|
||||
|
||||
====
|
||||
----
|
||||
<div>
|
||||
<!-- standard analytics code -->
|
||||
<script type="text/javascript">
|
||||
|
|
@ -110,7 +110,7 @@ To connect Gerrit to Google Analytics add the following to your
|
|||
};
|
||||
</script>
|
||||
</div>
|
||||
====
|
||||
----
|
||||
|
||||
Please consult the Google Analytics documentation for the correct
|
||||
setup code (the first two script tags). The above is shown only
|
||||
|
|
|
|||
|
|
@ -90,11 +90,11 @@ gerrit-plugin-api.jar::
|
|||
Plugins may provide optional description information with standard
|
||||
manifest fields:
|
||||
|
||||
====
|
||||
----
|
||||
Implementation-Title: Example plugin showing examples
|
||||
Implementation-Version: 1.0
|
||||
Implementation-Vendor: Example, Inc.
|
||||
====
|
||||
----
|
||||
|
||||
=== ApiType
|
||||
|
||||
|
|
@ -104,9 +104,9 @@ internals. If no `Gerrit-ApiType` is specified the stable `extension`
|
|||
API will be assumed. This may cause ClassNotFoundExceptions when
|
||||
loading a plugin that needs the plugin API.
|
||||
|
||||
====
|
||||
----
|
||||
Gerrit-ApiType: plugin
|
||||
====
|
||||
----
|
||||
|
||||
=== Explicit Registration
|
||||
|
||||
|
|
@ -119,20 +119,20 @@ server (if enabled). If no modules are named automatic registration
|
|||
will be performed by scanning all classes in the plugin JAR for
|
||||
`@Listen` and `@Export("")` annotations.
|
||||
|
||||
====
|
||||
----
|
||||
Gerrit-Module: tld.example.project.CoreModuleClassName
|
||||
Gerrit-SshModule: tld.example.project.SshModuleClassName
|
||||
Gerrit-HttpModule: tld.example.project.HttpModuleClassName
|
||||
====
|
||||
----
|
||||
|
||||
[[plugin_name]]
|
||||
=== Plugin Name
|
||||
|
||||
A plugin can optionally provide its own plugin name.
|
||||
|
||||
====
|
||||
----
|
||||
Gerrit-PluginName: replication
|
||||
====
|
||||
----
|
||||
|
||||
This is useful for plugins that contribute plugin-owned capabilities that
|
||||
are stored in the `project.config` file. Another use case is to be able to put
|
||||
|
|
@ -216,9 +216,9 @@ to be `restart`. Otherwise the preferred method of `reload` will
|
|||
be used, as it enables the server to hot-patch an updated plugin
|
||||
with no down time.
|
||||
|
||||
====
|
||||
----
|
||||
Gerrit-ReloadMode: restart
|
||||
====
|
||||
----
|
||||
|
||||
In either mode ('restart' or 'reload') any plugin or extension can
|
||||
be updated without restarting the Gerrit server. The difference is
|
||||
|
|
@ -259,9 +259,9 @@ For instance plugins to integrate Jira issues to Gerrit changes may
|
|||
contribute their own "init step" to allow configuring the Jira URL,
|
||||
credentials and possibly verify connectivity to validate them.
|
||||
|
||||
====
|
||||
----
|
||||
Gerrit-InitStep: tld.example.project.MyInitStep
|
||||
====
|
||||
----
|
||||
|
||||
MyInitStep needs to follow the standard Gerrit InitStep syntax
|
||||
and behavior: writing to the console using the injected ConsoleUI
|
||||
|
|
@ -1355,13 +1355,13 @@ A new button is placed on the popup dialog to actually send the request.
|
|||
Every `UiAction` exposes a REST API endpoint. The endpoint from the example above
|
||||
can be accessed from any REST client, i. e.:
|
||||
|
||||
====
|
||||
----
|
||||
curl -X POST -H "Content-Type: application/json" \
|
||||
-d '{message: "François", french: true}' \
|
||||
--digest --user joe:secret \
|
||||
http://host:port/a/changes/1/revisions/1/cookbook~say-hello
|
||||
"Bonjour François from change 1, patch set 1!"
|
||||
====
|
||||
----
|
||||
|
||||
A special case is to bind an endpoint without a view name. This is
|
||||
particularly useful for `DELETE` requests:
|
||||
|
|
|
|||
|
|
@ -6,9 +6,9 @@
|
|||
* Build the latest snapshot and install it into the local Maven
|
||||
repository:
|
||||
+
|
||||
====
|
||||
----
|
||||
mvn clean install
|
||||
====
|
||||
----
|
||||
|
||||
* Test Gerrit with this snapshot locally
|
||||
|
||||
|
|
@ -27,9 +27,9 @@ Configuration for Subprojects in `pom.xml`]
|
|||
|
||||
* Deploy the new snapshot:
|
||||
+
|
||||
====
|
||||
----
|
||||
mvn deploy
|
||||
====
|
||||
----
|
||||
|
||||
* Change the `id`, `bin_sha1`, and `src_sha1` values in the `maven_jar`
|
||||
for the subproject in `/lib/BUCK` to the `SNAPSHOT` version.
|
||||
|
|
@ -50,15 +50,15 @@ below)
|
|||
|
||||
* Create the Release Tag
|
||||
+
|
||||
====
|
||||
git tag -a -m "prolog-cafe 1.3" v1.3
|
||||
====
|
||||
----
|
||||
git tag -a -m "prolog-cafe 1.3" v1.3
|
||||
----
|
||||
|
||||
* Build and install into local Maven repository:
|
||||
+
|
||||
====
|
||||
----
|
||||
mvn clean install
|
||||
====
|
||||
----
|
||||
|
||||
|
||||
[[publish-release]]
|
||||
|
|
@ -72,18 +72,18 @@ link:dev-release-deploy-config.html#deploy-configuration-subprojects[subprojects
|
|||
|
||||
* Deploy the new release:
|
||||
+
|
||||
====
|
||||
----
|
||||
mvn deploy
|
||||
====
|
||||
----
|
||||
|
||||
* Push the pom change(s) to the project's repository
|
||||
`refs/for/<master|stable>`
|
||||
|
||||
* Push the Release Tag
|
||||
+
|
||||
====
|
||||
----
|
||||
git push gerrit-review refs/tags/v1.3:refs/tags/v1.3
|
||||
====
|
||||
----
|
||||
|
||||
|
||||
GERRIT
|
||||
|
|
|
|||
|
|
@ -358,20 +358,15 @@ homepage project] to change the version numbers to the new version.
|
|||
[[update-issues]]
|
||||
==== Update the Issues
|
||||
|
||||
====
|
||||
How do the issues get updated? Do you run a script to do
|
||||
this? When do you do it, after the final 2.5 is released?
|
||||
====
|
||||
|
||||
By hand.
|
||||
Update the issues by hand. There is no script for this.
|
||||
|
||||
Our current process is an issue should be updated to say `Status =
|
||||
Submitted, FixedIn-2.5` once the change is submitted, but before the
|
||||
release.
|
||||
|
||||
After the release is actually made, you can search in Google Code for
|
||||
``Status=Submitted FixedIn=2.5'' and then batch update these changes
|
||||
to say `Status=Released`. Make sure the pulldown says ``All Issues''
|
||||
`Status=Submitted FixedIn=2.5` and then batch update these changes
|
||||
to say `Status=Released`. Make sure the pulldown says `All Issues`
|
||||
because `Status=Submitted` is considered a closed issue.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -137,11 +137,11 @@ if existing Git repositories were not imported during 'init'.
|
|||
To control the Gerrit Code Review daemon that is running in the
|
||||
background, use the rc.d style start script created by 'init':
|
||||
|
||||
====
|
||||
----
|
||||
review_site/bin/gerrit.sh start
|
||||
review_site/bin/gerrit.sh stop
|
||||
review_site/bin/gerrit.sh restart
|
||||
====
|
||||
----
|
||||
|
||||
('Optional') Configure the daemon to automatically start and stop
|
||||
with the operating system.
|
||||
|
|
@ -149,18 +149,18 @@ with the operating system.
|
|||
Uncomment the following 3 lines in the `'$site_path/bin/gerrit.sh'`
|
||||
script:
|
||||
|
||||
====
|
||||
----
|
||||
chkconfig: 3 99 99
|
||||
description: Gerrit Code Review
|
||||
processname: gerrit
|
||||
====
|
||||
----
|
||||
|
||||
Then link the `gerrit.sh` script into `rc3.d`:
|
||||
|
||||
====
|
||||
----
|
||||
sudo ln -snf `pwd`/review_site/bin/gerrit.sh /etc/init.d/gerrit
|
||||
sudo ln -snf /etc/init.d/gerrit /etc/rc3.d/S90gerrit
|
||||
====
|
||||
----
|
||||
|
||||
('Optional') To enable autocompletion of the gerrit.sh commands, install
|
||||
autocompletion from the `/contrib/bash_completion` script. Refer to the
|
||||
|
|
|
|||
|
|
@ -69,11 +69,11 @@ Web UI. Otherwise you may inspect the history locally. If you have
|
|||
cloned the repository you can do this by executing the following
|
||||
commands:
|
||||
|
||||
====
|
||||
----
|
||||
$ git fetch origin refs/meta/config:config
|
||||
$ git checkout config
|
||||
$ git log project.config
|
||||
====
|
||||
----
|
||||
|
||||
Non project owners may still edit the access rights and propose the
|
||||
modifications to the project owners by clicking on the `Save for
|
||||
|
|
@ -519,11 +519,11 @@ Often comment links are used to link an ID in a commit message footer
|
|||
to an issue in an issue tracker system. For example, to link the ID
|
||||
from the `Bug` footer to Jira the following configuration can be used:
|
||||
|
||||
====
|
||||
----
|
||||
[commentlink "myjira"]
|
||||
match = ([Bb][Uu][Gg]:\\s+)(\\S+)
|
||||
link = https://myjira/browse/$2
|
||||
====
|
||||
----
|
||||
|
||||
[[reviewers]]
|
||||
== Reviewers
|
||||
|
|
@ -594,11 +594,11 @@ build, execute the tests or even do a deployment.
|
|||
The project-specific download commands must be configured in the
|
||||
`project.config` file in the `refs/meta/config` branch of the project:
|
||||
+
|
||||
====
|
||||
----
|
||||
[plugin "project-download-commands"]
|
||||
Build = git fetch ${url} ${ref} && git checkout FETCH_HEAD && buck build ${project}
|
||||
Update = git fetch ${url} ${ref} && git checkout FETCH_HEAD && git submodule update
|
||||
====
|
||||
----
|
||||
+
|
||||
Project-specific download commands that are defined on a parent project
|
||||
are inherited by the child projects. A child project can overwrite an
|
||||
|
|
@ -705,9 +705,9 @@ git filter-branch] command to rewrite the committer information for all
|
|||
commits (the author information that records who was writing the code
|
||||
stays intact; signed tags will lose their signature):
|
||||
|
||||
====
|
||||
----
|
||||
$ git filter-branch --tag-name-filter cat --env-filter 'GIT_COMMITTER_NAME="John Doe"; GIT_COMMITTER_EMAIL="john.doe@example.com";' -- --all
|
||||
====
|
||||
----
|
||||
|
||||
If a link:config-gerrit.html#receive.maxObjectSizeLimit[max object size
|
||||
limit] is configured on the server you may need to remove large objects
|
||||
|
|
@ -715,20 +715,22 @@ from the history before you are able to push. To find large objects in
|
|||
the history of your project you can use the `reposize.sh` script which
|
||||
you can download from Gerrit:
|
||||
|
||||
----
|
||||
$ curl -Lo reposize.sh http://review.example.com:8080/tools/scripts/reposize.sh
|
||||
|
||||
or
|
||||
|
||||
$ scp -p -P 29418 john.doe@review.example.com:scripts/reposize.sh .
|
||||
----
|
||||
|
||||
You can then use the
|
||||
link:https://www.kernel.org/pub/software/scm/git/docs/git-filter-branch.html[
|
||||
git filter-branch] command to remove the large objects from the history
|
||||
of all branches:
|
||||
|
||||
====
|
||||
----
|
||||
$ git filter-branch -f --index-filter 'git rm --cached --ignore-unmatch path/to/large-file.jar' -- --all
|
||||
====
|
||||
----
|
||||
|
||||
Since this command rewrites all commits in the repository it's a good
|
||||
idea to create a fresh clone from this rewritten repository before
|
||||
|
|
|
|||
|
|
@ -48,9 +48,9 @@ connectivity to the metadata database.
|
|||
== EXAMPLES
|
||||
To convert the local username of every account to lower case:
|
||||
|
||||
====
|
||||
----
|
||||
$ java -jar gerrit.war LocalUsernamesToLowerCase -d site_path
|
||||
====
|
||||
----
|
||||
|
||||
== SEE ALSO
|
||||
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ managed Git repositories.
|
|||
== EXAMPLES
|
||||
To manually correct a user's SSH user name:
|
||||
|
||||
====
|
||||
----
|
||||
$ java -jar gerrit.war gsql
|
||||
Welcome to Gerrit Code Review v2.0.25
|
||||
(PostgreSQL 8.3.8)
|
||||
|
|
@ -43,7 +43,7 @@ To manually correct a user's SSH user name:
|
|||
UPDATE 1; 1 ms
|
||||
gerrit> \q
|
||||
Bye
|
||||
====
|
||||
----
|
||||
|
||||
GERRIT
|
||||
------
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ and testing.
|
|||
== EXAMPLES
|
||||
Define a simple predicate and test it:
|
||||
|
||||
====
|
||||
----
|
||||
$ cat >simple.pl
|
||||
food(apple).
|
||||
food(orange).
|
||||
|
|
@ -45,7 +45,7 @@ Define a simple predicate and test it:
|
|||
|
||||
no
|
||||
| ?-
|
||||
====
|
||||
----
|
||||
|
||||
GERRIT
|
||||
------
|
||||
|
|
|
|||
|
|
@ -39,9 +39,9 @@ link:config-gerrit.html#cache.directory[cache.directory].
|
|||
== EXAMPLES
|
||||
To compile a rule JAR file for test/project:
|
||||
|
||||
====
|
||||
----
|
||||
$ java -jar gerrit.war rulec -d site_path test/project
|
||||
====
|
||||
----
|
||||
|
||||
GERRIT
|
||||
------
|
||||
|
|
|
|||
|
|
@ -22,9 +22,9 @@ manually].
|
|||
|
||||
. Create a Git repository under `gerrit.basePath`:
|
||||
+
|
||||
====
|
||||
----
|
||||
git --git-dir=$base_path/new/project.git init
|
||||
====
|
||||
----
|
||||
+
|
||||
[TIP]
|
||||
By tradition the repository directory name should have a `.git`
|
||||
|
|
@ -33,17 +33,17 @@ suffix.
|
|||
To also make this repository available over the anonymous git://
|
||||
protocol, don't forget to create a `git-daemon-export-ok` file:
|
||||
+
|
||||
====
|
||||
----
|
||||
touch $base_path/new/project.git/git-daemon-export-ok
|
||||
====
|
||||
----
|
||||
|
||||
. Register Project
|
||||
+
|
||||
Either restart the server, or flush the `project_list` cache:
|
||||
+
|
||||
====
|
||||
----
|
||||
ssh -p 29418 localhost gerrit flush-caches --cache project_list
|
||||
====
|
||||
----
|
||||
|
||||
[[project_options]]
|
||||
== Project Options
|
||||
|
|
@ -262,9 +262,9 @@ There are several ways to delete a branch:
|
|||
REST endpoint
|
||||
- by using a git client to force push nothing to an existing branch
|
||||
+
|
||||
====
|
||||
----
|
||||
$ git push --force origin :refs/heads/<branch-to-delete>
|
||||
====
|
||||
----
|
||||
|
||||
To be able to delete branches, the user must have the
|
||||
link:access-control.html#category_push[Push] access right with the
|
||||
|
|
|
|||
|
|
@ -92,14 +92,14 @@ Project specific submit rules are stored in the `rules.pl` file in the
|
|||
checkout the `refs/meta/config` branch in order to create or edit the `rules.pl`
|
||||
file:
|
||||
|
||||
====
|
||||
----
|
||||
$ git fetch origin refs/meta/config:config
|
||||
$ git checkout config
|
||||
... edit or create the rules.pl file
|
||||
$ git add rules.pl
|
||||
$ git commit -m "My submit rules"
|
||||
$ git push origin HEAD:refs/meta/config
|
||||
====
|
||||
----
|
||||
|
||||
[[HowToWriteSubmitRules]]
|
||||
== How to write submit rules
|
||||
|
|
@ -113,14 +113,14 @@ Conceptually we can imagine that Gerrit adds a set of facts about the change
|
|||
`C` on top of the `rules.pl` file and then consults it. The set of facts about
|
||||
the change `C` will look like:
|
||||
|
||||
====
|
||||
----
|
||||
:- package gerrit. <1>
|
||||
|
||||
commit_author(user(1000000), 'John Doe', 'john.doe@example.com'). <2>
|
||||
commit_committer(user(1000000), 'John Doe', 'john.doe@example.com'). <3>
|
||||
commit_message('Add plugin support to Gerrit'). <4>
|
||||
...
|
||||
====
|
||||
----
|
||||
|
||||
<1> Gerrit will provide its facts in a package named `gerrit`. This means we
|
||||
have to use qualified names when writing our code and referencing these facts.
|
||||
|
|
@ -139,9 +139,9 @@ needed criteria for the change to become submittable. This means that Gerrit has
|
|||
an expectation on the format and value of the result of the `submit_rule`
|
||||
predicate which is expected to be a `submit` term of the following format:
|
||||
|
||||
====
|
||||
----
|
||||
submit(label(label-name, status) [, label(label-name, status)]*)
|
||||
====
|
||||
----
|
||||
|
||||
where `label-name` is usually `'Code-Review'` or `'Verified'` but could also
|
||||
be any other string (see examples below). The `status` is one of:
|
||||
|
|
@ -173,11 +173,11 @@ needed for the change to become submittable.
|
|||
|
||||
Here some examples of possible return values from the `submit_rule` predicate:
|
||||
|
||||
====
|
||||
----
|
||||
submit(label('Code-Review', ok(_))) <1>
|
||||
submit(label('Code-Review', ok(_)), label('Verified', reject(_))) <2>
|
||||
submit(label('Author-is-John-Doe', need(_)) <3>
|
||||
====
|
||||
----
|
||||
|
||||
<1> label `'Code-Review'` is met. As there are no other labels in the
|
||||
return result, the change is submittable.
|
||||
|
|
@ -217,10 +217,9 @@ The purpose of the submit filter is, as its name says, to filter the results
|
|||
of the `submit_rule`. Therefore, the `submit_filter` predicate has two
|
||||
parameters:
|
||||
|
||||
====
|
||||
----
|
||||
submit_filter(In, Out) :- ...
|
||||
====
|
||||
|
||||
----
|
||||
Gerrit will invoke `submit_filter` with the `In` parameter containing a `submit`
|
||||
structure produced by the `submit_rule` and will take the value of the `Out`
|
||||
parameter as the result.
|
||||
|
|
@ -240,7 +239,7 @@ can avoid implementing the same `submit_rule` in all their projects.
|
|||
|
||||
The following "drawing" illustrates the order of the invocation and the chaining
|
||||
of the results of the `submit_rule` and `submit_filter` predicates.
|
||||
====
|
||||
----
|
||||
All-Projects
|
||||
^ submit_filter(B, S) :- ... <4>
|
||||
|
|
||||
|
|
@ -255,7 +254,7 @@ of the results of the `submit_rule` and `submit_filter` predicates.
|
|||
|
|
||||
MyProject
|
||||
submit_rule(X) :- ... <1>
|
||||
====
|
||||
----
|
||||
|
||||
<1> The `submit_rule` of `MyProject` is invoked first.
|
||||
<2> The result `X` is filtered through the `submit_filter` from the `Parent-1`
|
||||
|
|
@ -289,9 +288,9 @@ represents one of the supported submit types:
|
|||
Submit type filter works the same way as the xref:SubmitFilter[Submit Filter]
|
||||
where the name of the filter predicate is `submit_type_filter`.
|
||||
|
||||
====
|
||||
----
|
||||
submit_type_filter(In, Out).
|
||||
====
|
||||
----
|
||||
|
||||
Gerrit will invoke `submit_type_filter` with the `In` parameter containing a
|
||||
result of the `submit_type` and will take the value of the `Out` parameter as
|
||||
|
|
@ -306,9 +305,9 @@ command link:cmd-test-submit-rule.html[test-submit rule] loads a specific change
|
|||
and executes the `submit_rule`. It optionally reads the rule from from `stdin`
|
||||
to facilitate easy testing.
|
||||
|
||||
====
|
||||
----
|
||||
$ cat rules.pl | ssh gerrit_srv gerrit test-submit rule I45e080b105a50a625cc8e1fb5b357c0bfabe6d68 -s
|
||||
====
|
||||
----
|
||||
|
||||
== Prolog vs Gerrit plugin for project specific submit rules
|
||||
Since version 2.5 Gerrit supports plugins and extension points. A plugin or an
|
||||
|
|
|
|||
|
|
@ -45,24 +45,24 @@ branch. Consult link:access-control.html[access controls] for
|
|||
details on how access permissions work.
|
||||
|
||||
Initialize a temporary Git repository to edit the configuration:
|
||||
====
|
||||
----
|
||||
mkdir cfg_dir
|
||||
cd cfg_dir
|
||||
git init
|
||||
====
|
||||
----
|
||||
|
||||
Download the existing configuration from Gerrit:
|
||||
====
|
||||
----
|
||||
git fetch ssh://localhost:29418/project refs/meta/config
|
||||
git checkout FETCH_HEAD
|
||||
====
|
||||
----
|
||||
|
||||
Enable notifications to an email address by adding to
|
||||
`project.config`, this can be done using the `git config` command:
|
||||
====
|
||||
----
|
||||
git config -f project.config --add notify.team.email team-address@example.com
|
||||
git config -f project.config --add notify.team.email paranoid-manager@example.com
|
||||
====
|
||||
----
|
||||
|
||||
Examining the project.config file with any text editor should show
|
||||
a new notify section describing the email addresses to deliver to:
|
||||
|
|
@ -79,10 +79,10 @@ group it delivers to is typical. Multiple sections can be specified
|
|||
if different filters are needed.
|
||||
|
||||
Commit the configuration change, and push it back:
|
||||
====
|
||||
----
|
||||
git commit -a -m "Notify team-address@example.com of changes"
|
||||
git push ssh://localhost:29418/project HEAD:refs/meta/config
|
||||
====
|
||||
----
|
||||
|
||||
[[notify.name.email]]notify.<name>.email::
|
||||
+
|
||||
|
|
@ -132,11 +132,11 @@ has set the filtering options correctly. Project owners can implement
|
|||
security filtering by adding the `visibleto:groupname` predicate to
|
||||
the filter expression, for example:
|
||||
|
||||
====
|
||||
----
|
||||
[notify "Developers"]
|
||||
email = team-address@example.com
|
||||
filter = visibleto:Developers
|
||||
====
|
||||
----
|
||||
|
||||
When sending email to an internal group, the internal group's read
|
||||
access is automatically checked by Gerrit and therefore does not
|
||||
|
|
|
|||
|
|
@ -46,9 +46,9 @@ Also consider 'sub' available in a running Gerrit instance on "server".
|
|||
With this feature, one could attach 'sub' inside of 'super' repository
|
||||
at path 'sub' by executing the following command when being inside
|
||||
'super':
|
||||
====
|
||||
----
|
||||
git submodule add ssh://server/sub sub
|
||||
====
|
||||
----
|
||||
|
||||
Still considering the above example, after its execution notice that
|
||||
inside the local repository 'super' the 'sub' folder is considered a
|
||||
|
|
@ -56,9 +56,9 @@ gitlink to the external repository 'sub'. Also notice a file called
|
|||
.gitmodules is created (it is a configuration file containing the
|
||||
subscription of 'sub'). To provide the SHA-1 each gitlink points to in
|
||||
the external repository, one should use the command:
|
||||
====
|
||||
----
|
||||
git submodule status
|
||||
====
|
||||
----
|
||||
|
||||
In the example provided, if 'sub' is updated and 'super' is supposed
|
||||
to see the latest SHA-1 (considering here 'sub' has only the master
|
||||
|
|
@ -78,34 +78,34 @@ related information is allowed to be exposed in the superproject,
|
|||
the submodule needs to be configured to enable the superproject subscription.
|
||||
In a submodule client, checkout the refs/meta/config branch and edit
|
||||
the subscribe capabilities in the 'project.config' file:
|
||||
====
|
||||
----
|
||||
git fetch <remote> refs/meta/config:refs/meta/config
|
||||
git checkout refs/meta/config
|
||||
$EDITOR project.config
|
||||
====
|
||||
----
|
||||
and add the following lines:
|
||||
====
|
||||
----
|
||||
[allowSuperproject "<superproject>"]
|
||||
refs = <refspec>
|
||||
====
|
||||
----
|
||||
where the 'superproject' should be the exact project name of the superproject.
|
||||
The refspec defines which branches of the submodule are allowed to be
|
||||
subscribed to which branches of the superproject. See below for
|
||||
link:#acl_refspec[details]. Push the configuration for review and
|
||||
submit the change:
|
||||
====
|
||||
----
|
||||
git add project.config
|
||||
git commit -m "Allow <superproject> to subscribe"
|
||||
git push <remote> HEAD:refs/for/refs/meta/config
|
||||
====
|
||||
----
|
||||
After the change is integrated a superproject subscription is possible.
|
||||
|
||||
The configuration is inherited from parent projects, such that you can have
|
||||
a configuration in the "All-Projects" project like:
|
||||
====
|
||||
----
|
||||
[allowSuperproject "my-only-superproject"]
|
||||
refs = refs/heads/*:refs/heads/*
|
||||
====
|
||||
----
|
||||
and then you don't have to worry about configuring the individual projects
|
||||
any more. Child projects cannot negate the parent's configuration.
|
||||
|
||||
|
|
@ -152,25 +152,25 @@ to Git style RefSpecs used for pushing in Git. Regular expressions
|
|||
as found in the ACL configuration are not supported. The most restrictive
|
||||
RefSpec is allowing one specific branch of the submodule to be subscribed
|
||||
to one specific branch of the superproject via:
|
||||
====
|
||||
----
|
||||
[allowSuperproject "<superproject>"]
|
||||
refs = refs/heads/<submodule-branch>:refs/heads/<superproject-branch>
|
||||
====
|
||||
----
|
||||
|
||||
If you want to allow for a 1:1 mapping, i.e. 'master' maps to 'master',
|
||||
'stable' maps to 'stable', but not allowing 'master' to be subscribed to
|
||||
'stable':
|
||||
====
|
||||
----
|
||||
[allowSuperproject "<superproject>"]
|
||||
refs = refs/heads/*:refs/heads/*
|
||||
====
|
||||
----
|
||||
|
||||
If you want to enable a branch to be subscribed to any other branch of
|
||||
the superproject, omit the second part of the RefSpec:
|
||||
====
|
||||
----
|
||||
[allowSuperproject "<superproject>"]
|
||||
refs = refs/heads/<submodule-branch>
|
||||
====
|
||||
----
|
||||
|
||||
=== Subscription Limitations
|
||||
|
||||
|
|
|
|||
|
|
@ -54,16 +54,16 @@ Typically SSH keys are stored in your home directory, under `~/.ssh`.
|
|||
If you don't have any keys yet, you can create a new one and protect
|
||||
it with a passphrase:
|
||||
|
||||
====
|
||||
----
|
||||
ssh-keygen -t rsa
|
||||
====
|
||||
----
|
||||
|
||||
Then copy the content of the public key file onto your clipboard,
|
||||
and paste it into Gerrit's web interface:
|
||||
|
||||
====
|
||||
----
|
||||
cat ~/.ssh/id_rsa.pub
|
||||
====
|
||||
----
|
||||
|
||||
[TIP]
|
||||
Users who frequently upload changes will also want to consider
|
||||
|
|
@ -80,8 +80,7 @@ To verify your SSH key is working correctly, try using an SSH client
|
|||
to connect to Gerrit's SSHD port. By default Gerrit runs on
|
||||
port 29418, using the same hostname as the web server:
|
||||
|
||||
====
|
||||
..................................................................
|
||||
----
|
||||
$ ssh -p 29418 sshusername@hostname
|
||||
|
||||
**** Welcome to Gerrit Code Review ****
|
||||
|
|
@ -94,8 +93,7 @@ port 29418, using the same hostname as the web server:
|
|||
git clone ssh://sshusername@hostname:29418/REPOSITORY_NAME.git
|
||||
|
||||
Connection to hostname closed.
|
||||
..................................................................
|
||||
====
|
||||
----
|
||||
|
||||
In the command above, `sshusername` was configured as `Username` on
|
||||
the `Profile` tab of the `Settings` screen. If it is not set,
|
||||
|
|
@ -105,10 +103,10 @@ To determine the port number Gerrit is running on, visit the special
|
|||
information URL `http://'hostname'/ssh_info`, and copy the port
|
||||
number from the second field:
|
||||
|
||||
====
|
||||
----
|
||||
$ curl http://hostname/ssh_info
|
||||
hostname 29418
|
||||
====
|
||||
----
|
||||
|
||||
If you are developing an automated tool to perform uploads to Gerrit,
|
||||
let the user supply the hostname or the web address for Gerrit,
|
||||
|
|
@ -125,17 +123,17 @@ or `NOT_AVAILABLE` if the SSHD server is not currently running.
|
|||
To create new changes for review, simply push to the project's
|
||||
magical `refs/for/'branch'` ref using any Git client tool:
|
||||
|
||||
====
|
||||
----
|
||||
git push ssh://sshusername@hostname:29418/projectname HEAD:refs/for/branch
|
||||
====
|
||||
----
|
||||
|
||||
E.g. `john.doe` can use git push to upload new changes for the
|
||||
`experimental` branch of project `kernel/common`, hosted at the
|
||||
`git.example.com` Gerrit server:
|
||||
|
||||
====
|
||||
----
|
||||
git push ssh://john.doe@git.example.com:29418/kernel/common HEAD:refs/for/experimental
|
||||
====
|
||||
----
|
||||
|
||||
Each new commit uploaded by the `git push` client will be
|
||||
converted into a change record on the server. The remote ref
|
||||
|
|
@ -163,9 +161,9 @@ the `notify` option:
|
|||
|
||||
By default all email notifications are sent.
|
||||
|
||||
====
|
||||
----
|
||||
git push ssh://bot@git.example.com:29418/kernel/common HEAD:refs/for/master%notify=NONE
|
||||
====
|
||||
----
|
||||
|
||||
[[topic]]
|
||||
To include a short tag associated with all of the changes in the
|
||||
|
|
@ -174,17 +172,17 @@ the destination branch name. In this example the short topic tag
|
|||
'driver/i42' will be saved on each change this push creates or
|
||||
updates:
|
||||
|
||||
====
|
||||
----
|
||||
git push ssh://john.doe@git.example.com:29418/kernel/common HEAD:refs/for/experimental%topic=driver/i42
|
||||
====
|
||||
----
|
||||
|
||||
[[message]]
|
||||
A comment message can be applied to the change by using the `message` (or `m`)
|
||||
option:
|
||||
|
||||
====
|
||||
----
|
||||
git push ssh://john.doe@git.example.com:29418/kernel/common HEAD:refs/for/experimental%m=This_is_a_rebase_on_master
|
||||
====
|
||||
----
|
||||
|
||||
.Note
|
||||
****
|
||||
|
|
@ -196,16 +194,16 @@ it will then be applied as "This is a rebase on master".
|
|||
Review labels can be applied to the change by using the `label` (or `l`)
|
||||
option in the reference:
|
||||
|
||||
====
|
||||
----
|
||||
git push ssh://john.doe@git.example.com:29418/kernel/common HEAD:refs/for/experimental%l=Verified+1
|
||||
====
|
||||
----
|
||||
|
||||
The `l='label[score]'` option may be specified more than once to
|
||||
apply multiple review labels.
|
||||
|
||||
====
|
||||
----
|
||||
git push ssh://john.doe@git.example.com:29418/kernel/common HEAD:refs/for/experimental%l=Code-Review+1,l=Verified+1
|
||||
====
|
||||
----
|
||||
|
||||
The value is optional. If not specified, it defaults to +1 (if
|
||||
the label range allows it).
|
||||
|
|
@ -214,9 +212,9 @@ the label range allows it).
|
|||
A change edit can be pushed by specifying the `edit` (or `e`) option on
|
||||
the reference:
|
||||
|
||||
====
|
||||
----
|
||||
git push ssh://john.doe@git.example.com:29418/kernel/common HEAD:refs/for/master%edit
|
||||
====
|
||||
----
|
||||
|
||||
There is at most one change edit per user and change. In order to push
|
||||
a change edit the change must already exist.
|
||||
|
|
@ -232,7 +230,7 @@ consider adding an SSH host block in `~/.ssh/config` to remember
|
|||
your username, hostname and port number. This permits the use of
|
||||
shorter URLs on the command line, such as:
|
||||
|
||||
====
|
||||
----
|
||||
$ cat ~/.ssh/config
|
||||
...
|
||||
Host tr
|
||||
|
|
@ -241,15 +239,15 @@ shorter URLs on the command line, such as:
|
|||
User john.doe
|
||||
|
||||
$ git push tr:kernel/common HEAD:refs/for/experimental
|
||||
====
|
||||
----
|
||||
|
||||
Specific reviewers can be requested and/or additional 'carbon
|
||||
copies' of the notification message may be sent by including the
|
||||
`reviewer` (or `r`) and `cc` options in the reference:
|
||||
|
||||
====
|
||||
----
|
||||
git push tr:kernel/common HEAD:refs/for/experimental%r=a@a.com,cc=b@o.com
|
||||
====
|
||||
----
|
||||
|
||||
The `r='email'` and `cc='email'` options may be specified as many
|
||||
times as necessary to cover all interested parties. Gerrit will
|
||||
|
|
@ -261,7 +259,7 @@ If you are frequently sending changes to the same parties and/or
|
|||
branches, consider adding a custom remote block to your project's
|
||||
`.git/config` file:
|
||||
|
||||
====
|
||||
----
|
||||
$ cat .git/config
|
||||
...
|
||||
[remote "exp"]
|
||||
|
|
@ -269,7 +267,7 @@ branches, consider adding a custom remote block to your project's
|
|||
push = HEAD:refs/for/experimental%r=a@a.com,cc=b@o.com
|
||||
|
||||
$ git push exp
|
||||
====
|
||||
----
|
||||
|
||||
|
||||
[[push_replace]]
|
||||
|
|
@ -310,9 +308,9 @@ commit to the change's ref. For example, to add the commit whose
|
|||
SHA-1 starts with `c0ffee` as a new patch set for change number
|
||||
`1979`, use the push refspec `c0ffee:refs/changes/1979` as below:
|
||||
|
||||
====
|
||||
----
|
||||
git push ssh://sshusername@hostname:29418/projectname c0ffee:refs/changes/1979
|
||||
====
|
||||
----
|
||||
|
||||
This form can be combined together with `refs/for/'branchname'`
|
||||
(above) to simultaneously create new changes and replace changes
|
||||
|
|
@ -320,7 +318,7 @@ during one network transaction.
|
|||
|
||||
For example, consider the following sequence of events:
|
||||
|
||||
====
|
||||
----
|
||||
$ git commit -m A ; # create 3 commits
|
||||
$ git commit -m B
|
||||
$ git commit -m C
|
||||
|
|
@ -337,7 +335,7 @@ For example, consider the following sequence of events:
|
|||
HEAD~3:refs/changes/1500
|
||||
HEAD~1:refs/changes/1501
|
||||
HEAD~0:refs/changes/1502 ; # upload replacements
|
||||
====
|
||||
----
|
||||
|
||||
At the final step during the push Gerrit will attach A' as a new
|
||||
patch set on change 1500; B' as a new patch set on change 1501; C'
|
||||
|
|
@ -404,9 +402,9 @@ for teams that don't want to do code review but want to use Gerrit's
|
|||
submit strategies to handle contention on busy branches. Using
|
||||
`%submit` creates a change and submits it immediately:
|
||||
|
||||
====
|
||||
----
|
||||
git push ssh://john.doe@git.example.com:29418/kernel/common HEAD:refs/for/master%submit
|
||||
====
|
||||
----
|
||||
|
||||
On auto-merge of a change neither labels nor submit rules are checked.
|
||||
If the merge fails the change stays open, but when pushing a new patch
|
||||
|
|
@ -426,18 +424,18 @@ that have never before been seen by the Gerrit server. Clients
|
|||
may override that behavior and force new changes to be created
|
||||
by setting the merge base SHA-1 using the '%base' argument:
|
||||
|
||||
====
|
||||
----
|
||||
git push ssh://john.doe@git.example.com:29418/kernel/common HEAD:refs/for/master%base=$(git rev-parse origin/master)
|
||||
====
|
||||
----
|
||||
|
||||
It is also possible to specify more than one '%base' argument.
|
||||
This may be useful when pushing a merge commit. Note that the '%'
|
||||
character has only to be provided once, for the first '%base'
|
||||
argument:
|
||||
|
||||
====
|
||||
----
|
||||
git push ssh://john.doe@git.example.com:29418/kernel/common HEAD:refs/for/master%base=commit-id1,base=commit-id2
|
||||
====
|
||||
----
|
||||
|
||||
|
||||
== repo upload
|
||||
|
|
|
|||
Loading…
Reference in New Issue