Merge "Harmonize notation of admonition blocks in documentation"
This commit is contained in:
commit
bec50e107a
@ -1092,7 +1092,8 @@ the same permission then this 'ALLOW' rule overrides the 'BLOCK' rule:
|
|||||||
In this case a user which is a member of the group 'Y' will still be allowed to
|
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'.
|
push to 'refs/heads/*' even if it is a member of the group 'X'.
|
||||||
|
|
||||||
NOTE: An 'ALLOW' rule overrides a 'BLOCK' rule only when both of them are
|
[NOTE]
|
||||||
|
An 'ALLOW' rule overrides a 'BLOCK' rule only when both of them are
|
||||||
inside the same access section of the same project. An 'ALLOW' rule in a
|
inside the same access section of the same project. An 'ALLOW' rule in a
|
||||||
different access section of the same project or in any access section in an
|
different access section of the same project or in any access section in an
|
||||||
inheriting project cannot override a 'BLOCK' rule.
|
inheriting project cannot override a 'BLOCK' rule.
|
||||||
|
@ -20,7 +20,8 @@ Any user who has configured an SSH key.
|
|||||||
== SCRIPTING
|
== SCRIPTING
|
||||||
This command is intended to be used in scripts.
|
This command is intended to be used in scripts.
|
||||||
|
|
||||||
Note: this feature is only available if documentation index was built.
|
[NOTE]
|
||||||
|
This feature is only available if documentation index was built.
|
||||||
|
|
||||||
== EXAMPLES
|
== EXAMPLES
|
||||||
|
|
||||||
|
@ -141,7 +141,7 @@ branch.
|
|||||||
can represent an external system like CI that does automated verification
|
can represent an external system like CI that does automated verification
|
||||||
of the change. Comments with specific 'TAG' values can be filtered out in
|
of the change. Comments with specific 'TAG' values can be filtered out in
|
||||||
the web UI.
|
the web UI.
|
||||||
NOTE: To apply different tags on on different votes/comments multiple
|
Note that to apply different tags on on different votes/comments, multiple
|
||||||
invocations of the SSH command are required.
|
invocations of the SSH command are required.
|
||||||
|
|
||||||
== ACCESS
|
== ACCESS
|
||||||
|
@ -3108,7 +3108,8 @@ named `project/plugins/a` would be `CHERRY_PICK`.
|
|||||||
defaultSubmitType = CHERRY_PICK
|
defaultSubmitType = CHERRY_PICK
|
||||||
----
|
----
|
||||||
|
|
||||||
[NOTE] All properties are used from the matching repository configuration. In
|
[NOTE]
|
||||||
|
All properties are used from the matching repository configuration. In
|
||||||
the previous example, all properties will be used from `project/plugins/\*`
|
the previous example, all properties will be used from `project/plugins/\*`
|
||||||
section and no properties will be inherited nor overridden from `project/*`.
|
section and no properties will be inherited nor overridden from `project/*`.
|
||||||
|
|
||||||
|
@ -145,7 +145,8 @@ DirectoryIndex /cgi-bin/gitweb.cgi
|
|||||||
AllowOverride None
|
AllowOverride None
|
||||||
----
|
----
|
||||||
|
|
||||||
*NOTE* This may have already been added by yum/apt-get. If that's the case, leave as
|
[NOTE]
|
||||||
|
This may have already been added by yum/apt-get. If that's the case, leave as
|
||||||
is.
|
is.
|
||||||
|
|
||||||
===== Restart the Apache Web Server
|
===== Restart the Apache Web Server
|
||||||
|
@ -332,7 +332,8 @@ the `branch` as:
|
|||||||
Then *only* changes in above branch scope of parent project and child
|
Then *only* changes in above branch scope of parent project and child
|
||||||
projects will be affected by `Video-Qualify`.
|
projects will be affected by `Video-Qualify`.
|
||||||
|
|
||||||
NOTE: The `branch` is independent from the branch scope defined in `access`
|
[NOTE]
|
||||||
|
The `branch` is independent from the branch scope defined in `access`
|
||||||
parts in `project.config` file. That means from the UI a user can always
|
parts in `project.config` file. That means from the UI a user can always
|
||||||
assign permissions for that label on a branch, but this permission is then
|
assign permissions for that label on a branch, but this permission is then
|
||||||
ignored if the label doesn't apply for that branch.
|
ignored if the label doesn't apply for that branch.
|
||||||
|
@ -105,7 +105,8 @@ about our new key and can identify us by it.
|
|||||||
user@host:~$
|
user@host:~$
|
||||||
----
|
----
|
||||||
|
|
||||||
IMPORTANT: Please take note of the extra line-breaks introduced in the key above
|
[IMPORTANT]
|
||||||
|
Please take note of the extra line-breaks introduced in the key above
|
||||||
for formatting purposes. Please be sure to copy and paste your key without
|
for formatting purposes. Please be sure to copy and paste your key without
|
||||||
line-breaks.
|
line-breaks.
|
||||||
|
|
||||||
|
@ -105,7 +105,8 @@ To build the Gerrit web application that includes GWT UI and PolyGerrit UI:
|
|||||||
buck build gerrit
|
buck build gerrit
|
||||||
----
|
----
|
||||||
|
|
||||||
*Note: PolyGerrit UI may require additional tools (such as npm). Please read
|
[NOTE]
|
||||||
|
PolyGerrit UI may require additional tools (such as npm). Please read
|
||||||
the polygerrit-ui/README.md for more info.
|
the polygerrit-ui/README.md for more info.
|
||||||
|
|
||||||
The output executable WAR will be placed in:
|
The output executable WAR will be placed in:
|
||||||
|
@ -283,7 +283,8 @@ resulting from interactive work are logged to the console.
|
|||||||
== KNOWN ISSUES
|
== KNOWN ISSUES
|
||||||
The Inspector does not yet recognize Google Guice bindings.
|
The Inspector does not yet recognize Google Guice bindings.
|
||||||
|
|
||||||
IMPORTANT: Using the Inspector may void your warranty.
|
[IMPORTANT]
|
||||||
|
Using the Inspector may void your warranty.
|
||||||
|
|
||||||
GERRIT
|
GERRIT
|
||||||
------
|
------
|
||||||
|
@ -142,7 +142,8 @@ deployable to the `gerrit-maven` storage bucket:
|
|||||||
</distributionManagement>
|
</distributionManagement>
|
||||||
----
|
----
|
||||||
|
|
||||||
NOTE: In case of JGit the `pom.xml` already contains a distributionManagement
|
[NOTE]
|
||||||
|
In case of JGit the `pom.xml` already contains a distributionManagement
|
||||||
section. Replace the existing distributionManagement section with this snippet
|
section. Replace the existing distributionManagement section with this snippet
|
||||||
in order to deploy the artifacts only in the gerrit-maven repository.
|
in order to deploy the artifacts only in the gerrit-maven repository.
|
||||||
|
|
||||||
|
@ -1,12 +1,10 @@
|
|||||||
= Making a Gerrit Release
|
= Making a Gerrit Release
|
||||||
|
|
||||||
[NOTE]
|
[NOTE]
|
||||||
========================================================================
|
|
||||||
This document is meant primarily for Gerrit maintainers
|
This document is meant primarily for Gerrit maintainers
|
||||||
who have been given approval and submit status to the Gerrit
|
who have been given approval and submit status to the Gerrit
|
||||||
projects. Additionally, maintainers should be given owner
|
projects. Additionally, maintainers should be given owner
|
||||||
status to the Gerrit web site.
|
status to the Gerrit web site.
|
||||||
========================================================================
|
|
||||||
|
|
||||||
To make a Gerrit release involves a great deal of complex
|
To make a Gerrit release involves a great deal of complex
|
||||||
tasks and it is easy to miss a step so this document should
|
tasks and it is easy to miss a step so this document should
|
||||||
@ -34,16 +32,12 @@ need to undergo some stabilization before releasing the final release.
|
|||||||
* If needed create a Gerrit `RC1`
|
* If needed create a Gerrit `RC1`
|
||||||
|
|
||||||
[NOTE]
|
[NOTE]
|
||||||
========================================================================
|
|
||||||
You may let in a few features to this release
|
You may let in a few features to this release
|
||||||
========================================================================
|
|
||||||
|
|
||||||
* If needed create a Gerrit `RC2`
|
* If needed create a Gerrit `RC2`
|
||||||
|
|
||||||
[NOTE]
|
[NOTE]
|
||||||
========================================================================
|
|
||||||
There should be no new features in this release, only bug fixes
|
There should be no new features in this release, only bug fixes
|
||||||
========================================================================
|
|
||||||
|
|
||||||
* Finally create the `stable` release (no `RC`)
|
* Finally create the `stable` release (no `RC`)
|
||||||
|
|
||||||
|
@ -17,7 +17,8 @@ _ARCFOUR256_, and _ARCFOUR128_ can be enabled by downloading the _Java
|
|||||||
Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files_
|
Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files_
|
||||||
from Oracle and installing them into your JRE.
|
from Oracle and installing them into your JRE.
|
||||||
|
|
||||||
NOTE: Installing JCE extensions is optional and export restrictions may apply.
|
[NOTE]
|
||||||
|
Installing JCE extensions is optional and export restrictions may apply.
|
||||||
|
|
||||||
. Download the unlimited strength JCE policy files.
|
. Download the unlimited strength JCE policy files.
|
||||||
+
|
+
|
||||||
@ -82,7 +83,8 @@ own user account on the host system:
|
|||||||
java -jar gerrit.war init -d /path/to/your/gerrit_application_directory
|
java -jar gerrit.war init -d /path/to/your/gerrit_application_directory
|
||||||
----
|
----
|
||||||
|
|
||||||
'Please note:' If you choose a location where your new user doesn't
|
[NOTE]
|
||||||
|
If you choose a location where your new user doesn't
|
||||||
have any privileges, you may have to manually create the directory first and
|
have any privileges, you may have to manually create the directory first and
|
||||||
then give ownership of that location to the `'gerrit2'` user.
|
then give ownership of that location to the `'gerrit2'` user.
|
||||||
|
|
||||||
|
@ -4,7 +4,8 @@ Prior to invoking the `submit_rule(X)` query for a change, Gerrit initializes
|
|||||||
the Prolog engine with a set of facts (current data) about this change.
|
the Prolog engine with a set of facts (current data) about this change.
|
||||||
The following table provides an overview of the provided facts.
|
The following table provides an overview of the provided facts.
|
||||||
|
|
||||||
IMPORTANT: All the terms listed below are defined in the `gerrit` package. To use any
|
[IMPORTANT]
|
||||||
|
All the terms listed below are defined in the `gerrit` package. To use any
|
||||||
of them we must use a qualified name like `gerrit:change_branch(X)`.
|
of them we must use a qualified name like `gerrit:change_branch(X)`.
|
||||||
|
|
||||||
.Prolog facts about the current change
|
.Prolog facts about the current change
|
||||||
@ -97,7 +98,8 @@ the following table.
|
|||||||
|
|
||||||
|=============================================================================
|
|=============================================================================
|
||||||
|
|
||||||
NOTE: for a complete list of built-in helpers read the `gerrit_common.pl` and
|
[NOTE]
|
||||||
|
For a complete list of built-in helpers read the `gerrit_common.pl` and
|
||||||
all Java classes whose name matches `PRED_*.java` from Gerrit's source code.
|
all Java classes whose name matches `PRED_*.java` from Gerrit's source code.
|
||||||
|
|
||||||
GERRIT
|
GERRIT
|
||||||
|
@ -17,7 +17,8 @@ define a set of criteria which must be fulfilled for a change to become
|
|||||||
submittable. For a change that is not submittable, the set of needed criteria
|
submittable. For a change that is not submittable, the set of needed criteria
|
||||||
is displayed in the Gerrit UI.
|
is displayed in the Gerrit UI.
|
||||||
|
|
||||||
NOTE: Loading and executing Prolog submit rules may be disabled by setting
|
[NOTE]
|
||||||
|
Loading and executing Prolog submit rules may be disabled by setting
|
||||||
`rules.enable=false` in the Gerrit config file (see
|
`rules.enable=false` in the Gerrit config file (see
|
||||||
link:config-gerrit.html#_a_id_rules_a_section_rules[rules section])
|
link:config-gerrit.html#_a_id_rules_a_section_rules[rules section])
|
||||||
|
|
||||||
@ -73,7 +74,8 @@ For interactive testing and playing with Prolog, Gerrit provides the
|
|||||||
link:pgm-prolog-shell.html[prolog-shell] program which opens an interactive
|
link:pgm-prolog-shell.html[prolog-shell] program which opens an interactive
|
||||||
Prolog interpreter shell.
|
Prolog interpreter shell.
|
||||||
|
|
||||||
NOTE: The interactive shell is just a prolog shell, it does not load
|
[NOTE]
|
||||||
|
The interactive shell is just a prolog shell, it does not load
|
||||||
a gerrit server environment and thus is not intended for
|
a gerrit server environment and thus is not intended for
|
||||||
xref:TestingSubmitRules[testing submit rules].
|
xref:TestingSubmitRules[testing submit rules].
|
||||||
|
|
||||||
@ -160,10 +162,12 @@ be any other string (see examples below). The `status` is one of:
|
|||||||
could either be set or unset without ever influencing whether the change
|
could either be set or unset without ever influencing whether the change
|
||||||
could be submitted.
|
could be submitted.
|
||||||
|
|
||||||
NOTE: For a change to be submittable all `label` terms contained in the returned
|
[NOTE]
|
||||||
|
For a change to be submittable all `label` terms contained in the returned
|
||||||
`submit` term must have either `ok` or `may` status.
|
`submit` term must have either `ok` or `may` status.
|
||||||
|
|
||||||
IMPORTANT: Gerrit will let the Prolog engine continue searching for solutions of
|
[IMPORTANT]
|
||||||
|
Gerrit will let the Prolog engine continue searching for solutions of
|
||||||
the `submit_rule(X)` query until it finds the first one where all labels in the
|
the `submit_rule(X)` query until it finds the first one where all labels in the
|
||||||
return result have either status `ok` or `may` or there are no more solutions.
|
return result have either status `ok` or `may` or there are no more solutions.
|
||||||
If a solution where all labels have status `ok` is found then all previously
|
If a solution where all labels have status `ok` is found then all previously
|
||||||
@ -229,7 +233,8 @@ next `submit_filter` in the parent line. The value of the `Out` parameter
|
|||||||
of the top-most `submit_filter` is the final result of the submit rule that
|
of the top-most `submit_filter` is the final result of the submit rule that
|
||||||
is used to decide whether a change is submittable or not.
|
is used to decide whether a change is submittable or not.
|
||||||
|
|
||||||
IMPORTANT: `submit_filter` is a mechanism for Gerrit administrators to implement
|
[IMPORTANT]
|
||||||
|
`submit_filter` is a mechanism for Gerrit administrators to implement
|
||||||
and enforce submit rules that would apply to all projects while `submit_rule` is
|
and enforce submit rules that would apply to all projects while `submit_rule` is
|
||||||
a mechanism for project owners to implement project specific submit rules.
|
a mechanism for project owners to implement project specific submit rules.
|
||||||
However, project owners who own several projects could also make use of
|
However, project owners who own several projects could also make use of
|
||||||
@ -266,7 +271,8 @@ a `submit_filter` it is skipped.
|
|||||||
`submit_filter` in the `All-Projects` project. The value in `S` is the final
|
`submit_filter` in the `All-Projects` project. The value in `S` is the final
|
||||||
value of the submit rule evaluation.
|
value of the submit rule evaluation.
|
||||||
|
|
||||||
NOTE: If `MyProject` doesn't define its own `submit_rule` Gerrit will invoke the
|
[NOTE]
|
||||||
|
If `MyProject` doesn't define its own `submit_rule` Gerrit will invoke the
|
||||||
default implementation of submit rule that is named `gerrit:default_submit` and
|
default implementation of submit rule that is named `gerrit:default_submit` and
|
||||||
its result will be filtered as described above.
|
its result will be filtered as described above.
|
||||||
|
|
||||||
@ -561,7 +567,8 @@ starts_with(L, []).
|
|||||||
starts_with([H|T1], [H|T2]) :- starts_with(T1, T2).
|
starts_with([H|T1], [H|T2]) :- starts_with(T1, T2).
|
||||||
----
|
----
|
||||||
|
|
||||||
NOTE: The `name/2` embedded predicate is used to convert a string symbol into a
|
[NOTE]
|
||||||
|
The `name/2` embedded predicate is used to convert a string symbol into a
|
||||||
list of characters. A string `abc` is converted into a list of characters `[97,
|
list of characters. A string `abc` is converted into a list of characters `[97,
|
||||||
98, 99]`. A double quoted string in Prolog is just a shortcut for creating a
|
98, 99]`. A double quoted string in Prolog is just a shortcut for creating a
|
||||||
list of characters. `"abc"` is a shortcut for `[97, 98, 99]`. This is why we use
|
list of characters. `"abc"` is a shortcut for `[97, 98, 99]`. This is why we use
|
||||||
|
@ -184,11 +184,9 @@ option:
|
|||||||
git push ssh://john.doe@git.example.com:29418/kernel/common HEAD:refs/for/experimental%m=This_is_a_rebase_on_master
|
git push ssh://john.doe@git.example.com:29418/kernel/common HEAD:refs/for/experimental%m=This_is_a_rebase_on_master
|
||||||
----
|
----
|
||||||
|
|
||||||
.Note
|
[NOTE]
|
||||||
****
|
|
||||||
git push refs parameter does not allow spaces. Use the '_' character instead,
|
git push refs parameter does not allow spaces. Use the '_' character instead,
|
||||||
it will then be applied as "This is a rebase on master".
|
it will then be applied as "This is a rebase on master".
|
||||||
****
|
|
||||||
|
|
||||||
[[review_labels]]
|
[[review_labels]]
|
||||||
Review labels can be applied to the change by using the `label` (or `l`)
|
Review labels can be applied to the change by using the `label` (or `l`)
|
||||||
@ -291,8 +289,8 @@ For more about Change-Ids, see link:user-changeid.html[Change-Id Lines].
|
|||||||
[[manual_replacement_mapping]]
|
[[manual_replacement_mapping]]
|
||||||
==== Manual Replacement Mapping
|
==== Manual Replacement Mapping
|
||||||
|
|
||||||
.Note
|
[NOTE]
|
||||||
****
|
--
|
||||||
The remainder of this section describes a manual method of replacing
|
The remainder of this section describes a manual method of replacing
|
||||||
changes by matching each commit name to an existing change number.
|
changes by matching each commit name to an existing change number.
|
||||||
End-users should instead prefer to use Change-Id lines in their
|
End-users should instead prefer to use Change-Id lines in their
|
||||||
@ -300,7 +298,7 @@ commit messages, as the process is then fully automated by Gerrit
|
|||||||
during normal uploads.
|
during normal uploads.
|
||||||
|
|
||||||
See above for the preferred technique of replacing changes.
|
See above for the preferred technique of replacing changes.
|
||||||
****
|
--
|
||||||
|
|
||||||
To add an additional patch set to a change, replacing it with an
|
To add an additional patch set to a change, replacing it with an
|
||||||
updated version of the same logical modification, send the new
|
updated version of the same logical modification, send the new
|
||||||
|
Loading…
Reference in New Issue
Block a user