Documentation/config-submit-requirements.txt - gerrit - Git at Google

 = Gerrit Code Review - Submit Requirements

 As part of the code review process, project owners need to configure rules that
 govern when changes become submittable. For example, an admin might want to
 prevent changes from being submittable until at least a “+2” vote on the
 “Code-Review” label is granted on a change. Admins can define submit
 requirements to enforce submittability rules for changes.

 [[configuring_submit_requirements]]
 == Configuring Submit Requirements

 Site administrators and project owners can define submit requirements in the
 link:config-project-config.html[project config]. A submit requirement has the
 following fields:


 [[submit_requirement_name]]
 === submit-requirement.Name

 A name that uniquely identifies the submit requirement. Submit requirements
 can be overridden in child projects if they are defined with the same name in
 the child project. See the link:#inheritance[inheritance] section for more
 details.

 [[submit_requirement_description]]
 === submit-requirement.Name.description

 A detailed description of what the submit requirement is supposed to do. This
 field is optional. The description is visible to the users in the change page
 upon hovering on the submit requirement to help them understand what the
 requirement is about and how it can be fulfilled.

 [[submit_requirement_applicable_if]]
 === submit-requirement.Name.applicableIf

 A link:#query_expression_syntax[query expression] that determines if the submit
 requirement is applicable for a change. For example, administrators can exclude
 submit requirements for certain branch patterns. See the
 link:#exempt-branch-example[exempt branch] example.

 Often submit requirements should only apply to branches that contain source
 code. In this case this parameter can be used to exclude the
 link:config-project-config.html#refs-meta-config[refs/meta/config] branch from
 a submit requirement:

 ----
   applicableIf = -branch:refs/meta/config
 ----

 This field is optional, and if not specified, the submit requirement is
 considered applicable for all changes in the project.

 [[submit_requirement_submittable_if]]
 === submit-requirement.Name.submittableIf

 A link:#query_expression_syntax[query expression] that determines when the
 change becomes submittable. This field is mandatory.


 [[submit_requirement_override_if]]
 === submit-requirement.Name.overrideIf

 A link:#query_expression_syntax[query expression] that controls when the
 submit requirement is overridden. When this expression is evaluated to true,
 the submit requirement state becomes `OVERRIDDEN` and the submit requirement
 is no longer blocking the change submission.
 This expression can be used to enable bypassing the requirement in some
 circumstances, for example if the change owner is a power user or to allow
 change submission in case of emergencies. +

 This field is optional.

 [[submit_requirement_can_override_in_child_projects]]
 === submit-requirement.Name.canOverrideInChildProjects

 A boolean (true, false) that determines if child projects can override the
 submit requirement. +

 The default value is `false`.

 [[evaluation_results]]
 == Evaluation Results

 When submit requirements are configured, their results are returned for all
 changes requested by the REST API with the
 link:rest-api-changes.html#submit-requirement-result-info[SubmitRequirementResultInfo]
 entity. +

 Submit requirement results are produced from the evaluation of the submit
 requirements in the project config (
 See link:#configuring_submit_requirements[Configuring Submit Requirements])
 as well as the conversion of the results of the legacy submit rules to submit
 requirement results. Legacy submit rules are label functions
 (see link:config-labels.html[config labels]), custom and
 link:prolog-cookbook.html[prolog] submit rules.

 The `status` field can be one of:

 * `NOT_APPLICABLE`
 +
 The link:#submit_requirement_applicable_if[applicableIf] expression evaluates
 to false for the change.

 * `UNSATISFIED`
 +
 The submit requirement is applicable
 (link:#submit_requirement_applicable_if[applicableIf] evaluates to true), but
 the evaluation of the link:#submit_requirement_submittable_if[submittableIf] and
 link:#submit_requirement_override_if[overrideIf] expressions return false for
 the change.

 * `SATISFIED`
 +
 The submit requirement is applicable
 (link:#submit_requirement_applicable_if[applicableIf] evaluates to true), the
 link:#submit_requirement_submittable_if[submittableIf] expression evaluates to
 true, and the link:#submit_requirement_override_if[overrideIf] evaluates to
 false for the change.

 * `OVERRIDDEN`
 +
 The submit requirement is applicable
 (link:#submit_requirement_applicable_if[applicableIf] evaluates to true) and the
 link:#submit_requirement_override_if[overrideIf] expression evaluates to true.
 +
 Note that in this case, the change is overridden whether the
 link:#submit_requirement_submittable_if[submittableIf] expression evaluates to
 true or not.

 * `BYPASSED`
 +
 The change was merged directly bypassing code review by supplying the
 link:user-upload.html#auto_merge[submit] push option while doing a git push.

 * `ERROR`
 +
 The evaluation of any of the
 link:#submit_requirement_applicable_if[applicableIf],
 link:#submit_requirement_submittable_if[submittableIf] or
 link:#submit_requirement_override_if[overrideIf] expressions resulted in an
 error.


 [[query_expression_syntax]]
 == Query Expression Syntax

 All applicableIf, submittableIf and overrideIf expressions use the same syntax
 and operators available for link:user-search.html[searching changes]. In
 addition to that, submit requirements support extra operators.


 [[submit_requirements_operators]]
 === Submit Requirements Operators

 [[operator_authoremail]]
 authoremail:'EMAIL_PATTERN'::
 +
 An operator that returns true if the change author's email address matches a
 specific regular expression pattern. The
 link:http://www.brics.dk/automaton/[dk.brics.automaton library,role=external,window=_blank]
 is used for the evaluation of such patterns.

 [[operator_committeremail]]
 committeremail:'EMAIL_PATTERN'::
 +
 An operator that returns true if the change committer's email address matches a
 specific regular expression pattern. The
 link:http://www.brics.dk/automaton/[dk.brics.automaton library,role=external,window=_blank]
 is used for the evaluation of such patterns.

 [[operator_uploaderemail]]
 uploaderemail:'EMAIL_PATTERN'::
 +
 An operator that returns true if the change uploader's primary email address
 matches a specific regular expression pattern. The
 link:http://www.brics.dk/automaton/[dk.brics.automaton library,role=external,window=_blank]
 is used for the evaluation of such patterns.

 [[operator_distinctvoters]]
 distinctvoters:'[Label1,Label2,...,LabelN],value=MAX,count>1'::
 +
 An operator that allows checking for distinct voters across more than one label.
 +
 2..N labels are supported, filtering by a value (MIN,MAX,integer) is optional.
 Count is mandatory.
 +
 Examples:
 `distinctvoters:[Code-Review,Trust],value=MAX,count>1`
 +
 `distinctvoters:[Code-Review,Trust,API-Review],count>2`

 [[operator_is_true]]
 is:true::
 +
 An operator that always returns true for all changes. An example usage is to
 redefine a submit requirement in a child project and make the submit requirement
 always applicable.

 [[operator_is_false]]
 is:false::
 +
 An operator that always returns false for all changes. An example usage is to
 redefine a submit requirement in a child project and make the submit requirement
 always non-applicable.

 [[operator_has_submodule_update]]
 has:submodule-update::
 +
 An operator that returns true if the diff of the latest patchset against the
 default parent has a submodule modified file, that is, a ".gitmodules" or a
 git link file.
 +
 The optional `base` parameter can also be supplied for merge commits like
 `has:submodule-update,base=1`, or `has:submodule-update,base=2`. In these cases,
 the operator returns true if the diff of the latest patchset against parent
 number identified by `base` has a submodule modified file. Note that the
 operator will return false if the base parameter is greater than the number of
 parents for the latest patchset for the change.

 [[operator_file]]
 file:"'<filePattern>',withDiffContaining='<contentPattern>'"::
 +
 An operator that returns true if the latest patchset contained a modified file
 matching `<filePattern>` with a modified region matching `<contentPattern>`.
 +
 Both `<filePattern>` and `<contentPattern>` support regular expressions if they
 start with the '^' character. Regular expressions are matched with the
 `java.util.regex` engine. When using regular expressions, special characters
 should be double escaped because the config is parsed twice when the server
 reads the `project.config` file and when the submit-requirement expressions
 are parsed as a predicate tree. For example, to match against modified files
 that end with ".cc" or ".cpp" the following `applicableIf` expression can be
 used:
 +
 ----
   applicableIf = file:\"^.*\\\\.(cc|cpp)$\"
 ----
 +
 Below is another example that uses both `<filePattern>` and `<contentPattern>`:
 +
 ----
   applicableIf = file:\"'^.*\\\\.(cc|cpp)$',withDiffContaining='^.*th[rR]ee$'\"
 ----
 +
 If no regular expression is used, the text is matched by checking that the file
 name contains the file pattern, or the edits of the file diff contain the edit
 pattern.

 [[operator_label]]
 label:labelName=+1,user=non_contributor::
 +
 Submit requirements support an additional `user=non_contributor` argument for
 labels that returns true if the change has a label vote matching the specified
 value and the vote is applied from a gerrit account that's not the uploader,
 author or committer of the latest patchset. See the documentation for the labels
 operator in the link:user-search.html[user search] page.

 [[unsupported_operators]]
 === Unsupported Operators

 Some operators are not supported with submit requirement expressions.

 [[operator_is_submittable]]
 is:submittable::
 +
 Cannot be used since it will result in recursive evaluation of expressions.

 [[inheritance]]
 == Inheritance

 Child projects can override a submit requirement defined in any of their parent
 projects. Overriding a submit requirement overrides all of its properties and
 values. The overriding project needs to define all mandatory fields.

 Submit requirements are looked up from the current project up the inheritance
 hierarchy to “All-Projects”. The first project in the hierarchy chain that sets
 link:#submit_requirement_can_override_in_child_projects[canOverrideInChildProjects]
 to false prevents all descendant projects from overriding it.

 If a project disallows a submit requirement from being overridden in child
 projects, all definitions of this submit requirement in descendant projects are
 ignored.

 To remove a submit requirement in a child project, administrators can redefine
 the requirement with the same name in the child project and set the
 link:#submit_requirement_applicable_if[applicableIf] expression to `is:false`.
 Since the link:#submit_requirement_submittable_if[submittableIf] field is
 mandatory, administrators need to provide it in the child project but can set it
 to anything, for example `is:false` but it will have no effect anyway.


 [[trigger-votes]]
 == Trigger Votes

 Trigger votes are label votes that are not associated with any submit
 requirement expressions. Trigger votes are displayed in a separate section in
 the change page. For more about configuring labels, see the
 link:config-labels.html[config labels] documentation.


 [[examples]]
 == Examples

 [[code-review-example]]
 === Code-Review Example

 To define a submit requirement for code-review that requires a maximum vote for
 the “Code-Review” label from a non-uploader without a maximum negative vote:

 ----
 [submit-requirement "Code-Review"]
 	description = A maximum vote from a non-uploader is required for the \
 	              'Code-Review' label. A minimum vote is blocking.
 	submittableIf = label:Code-Review=MAX,user=non_uploader AND -label:Code-Review=MIN
 	canOverrideInChildProjects = true
 ----

 [[exempt-branch-example]]
 === Exempt a branch Example

 We could exempt a submit requirement from certain branches. For example,
 project owners might want to skip the 'Code-Style' requirement from the
 refs/meta/config branch.

 ----
 [submit-requirement "Code-Style"]
   description = Code is properly styled and formatted
   applicableIf = -branch:refs/meta/config
   submittableIf = label:Code-Style=+1 AND -label:Code-Style=-1
   canOverrideInChildProjects = true
 ----

 Branch configuration supports regular expressions as well, e.g. to exempt 'refs/heads/release/*' pattern,
 when migrating from the label Submit-Rule:

 ----
 [label "Verified"]
   branch = refs/heads/release/*
 ----

 The following SR can be configured:

 ----
 [submit-requirement "Verified"]
   submittableIf = label:Verified=MAX AND -label:Verified=MIN
   applicableIf = branch:^refs/heads/release/.*
 ----

 [[require-footer-example]]
 === Require a footer Example

 It's possible to use a submit requirement to require a footer to be present in
 the commit message.

 ----
 [submit-requirement "Bug-Footer"]
   description = Changes must include a 'Bug' footer
   applicableIf = -branch:refs/meta/config AND -hasfooter:\"Bug\"
   submittableIf = hasfooter:\"Bug\"
 ----

 [[test-submit-requirements]]
 == Testing Submit Requirements

 The link:rest-api-changes.html#check-submit-requirement[Check Submit Requirement]
 change endpoint can be used to test submit requirements on any change. Users
 are encouraged to test submit requirements before adding them to the project
 to ensure they work as intended.

 .Request
 ----
   POST /changes/myProject~master~I8473b95934b5732ac55d26311a706c9c2bde9940/check.submit_requirement HTTP/1.0
   Content-Type: application/json; charset=UTF-8

     {
       "name": "Code-Review",
       "submittability_expression": "label:Code-Review=+2"
     }
 ----

 .Response
 ----
   HTTP/1.1 200 OK
   Content-Disposition: attachment
   Content-Type: application/json; charset=UTF-8

   )]}'
   {
     "name": "Code-Review",
     "status": "SATISFIED",
     "submittability_expression_result": {
       "expression": "label:Code-Review=+2",
       "fulfilled": true,
       "passingAtoms": [
         "label:Code-Review=+2"
       ]
     },
     "is_legacy": false
   }
 ----

 GERRIT
 ------
 Part of link:index.html[Gerrit Code Review]

 SEARCHBOX
 ---------
	= Gerrit Code Review - Submit Requirements

	As part of the code review process, project owners need to configure rules that
	govern when changes become submittable. For example, an admin might want to
	prevent changes from being submittable until at least a “+2” vote on the
	“Code-Review” label is granted on a change. Admins can define submit
	requirements to enforce submittability rules for changes.

	[[configuring_submit_requirements]]
	== Configuring Submit Requirements

	Site administrators and project owners can define submit requirements in the
	link:config-project-config.html[project config]. A submit requirement has the
	following fields:


	[[submit_requirement_name]]
	=== submit-requirement.Name

	A name that uniquely identifies the submit requirement. Submit requirements
	can be overridden in child projects if they are defined with the same name in
	the child project. See the link:#inheritance[inheritance] section for more
	details.

	[[submit_requirement_description]]
	=== submit-requirement.Name.description

	A detailed description of what the submit requirement is supposed to do. This
	field is optional. The description is visible to the users in the change page
	upon hovering on the submit requirement to help them understand what the
	requirement is about and how it can be fulfilled.

	[[submit_requirement_applicable_if]]
	=== submit-requirement.Name.applicableIf

	A link:#query_expression_syntax[query expression] that determines if the submit
	requirement is applicable for a change. For example, administrators can exclude
	submit requirements for certain branch patterns. See the
	link:#exempt-branch-example[exempt branch] example.

	Often submit requirements should only apply to branches that contain source
	code. In this case this parameter can be used to exclude the
	link:config-project-config.html#refs-meta-config[refs/meta/config] branch from
	a submit requirement:

	----
	applicableIf = -branch:refs/meta/config
	----

	This field is optional, and if not specified, the submit requirement is
	considered applicable for all changes in the project.

	[[submit_requirement_submittable_if]]
	=== submit-requirement.Name.submittableIf

	A link:#query_expression_syntax[query expression] that determines when the
	change becomes submittable. This field is mandatory.


	[[submit_requirement_override_if]]
	=== submit-requirement.Name.overrideIf

	A link:#query_expression_syntax[query expression] that controls when the
	submit requirement is overridden. When this expression is evaluated to true,
	the submit requirement state becomes `OVERRIDDEN` and the submit requirement
	is no longer blocking the change submission.
	This expression can be used to enable bypassing the requirement in some
	circumstances, for example if the change owner is a power user or to allow
	change submission in case of emergencies. +

	This field is optional.

	[[submit_requirement_can_override_in_child_projects]]
	=== submit-requirement.Name.canOverrideInChildProjects

	A boolean (true, false) that determines if child projects can override the
	submit requirement. +

	The default value is `false`.

	[[evaluation_results]]
	== Evaluation Results

	When submit requirements are configured, their results are returned for all
	changes requested by the REST API with the
	link:rest-api-changes.html#submit-requirement-result-info[SubmitRequirementResultInfo]
	entity. +

	Submit requirement results are produced from the evaluation of the submit
	requirements in the project config (
	See link:#configuring_submit_requirements[Configuring Submit Requirements])
	as well as the conversion of the results of the legacy submit rules to submit
	requirement results. Legacy submit rules are label functions
	(see link:config-labels.html[config labels]), custom and
	link:prolog-cookbook.html[prolog] submit rules.

	The `status` field can be one of:

	* `NOT_APPLICABLE`
	+
	The link:#submit_requirement_applicable_if[applicableIf] expression evaluates
	to false for the change.

	* `UNSATISFIED`
	+
	The submit requirement is applicable
	(link:#submit_requirement_applicable_if[applicableIf] evaluates to true), but
	the evaluation of the link:#submit_requirement_submittable_if[submittableIf] and
	link:#submit_requirement_override_if[overrideIf] expressions return false for
	the change.

	* `SATISFIED`
	+
	The submit requirement is applicable
	(link:#submit_requirement_applicable_if[applicableIf] evaluates to true), the
	link:#submit_requirement_submittable_if[submittableIf] expression evaluates to
	true, and the link:#submit_requirement_override_if[overrideIf] evaluates to
	false for the change.

	* `OVERRIDDEN`
	+
	The submit requirement is applicable
	(link:#submit_requirement_applicable_if[applicableIf] evaluates to true) and the
	link:#submit_requirement_override_if[overrideIf] expression evaluates to true.
	+
	Note that in this case, the change is overridden whether the
	link:#submit_requirement_submittable_if[submittableIf] expression evaluates to
	true or not.

	* `BYPASSED`
	+
	The change was merged directly bypassing code review by supplying the
	link:user-upload.html#auto_merge[submit] push option while doing a git push.

	* `ERROR`
	+
	The evaluation of any of the
	link:#submit_requirement_applicable_if[applicableIf],
	link:#submit_requirement_submittable_if[submittableIf] or
	link:#submit_requirement_override_if[overrideIf] expressions resulted in an
	error.


	[[query_expression_syntax]]
	== Query Expression Syntax

	All applicableIf, submittableIf and overrideIf expressions use the same syntax
	and operators available for link:user-search.html[searching changes]. In
	addition to that, submit requirements support extra operators.


	[[submit_requirements_operators]]
	=== Submit Requirements Operators

	[[operator_authoremail]]
	authoremail:'EMAIL_PATTERN'::
	+
	An operator that returns true if the change author's email address matches a
	specific regular expression pattern. The
	link:http://www.brics.dk/automaton/[dk.brics.automaton library,role=external,window=_blank]
	is used for the evaluation of such patterns.

	[[operator_committeremail]]
	committeremail:'EMAIL_PATTERN'::
	+
	An operator that returns true if the change committer's email address matches a
	specific regular expression pattern. The
	link:http://www.brics.dk/automaton/[dk.brics.automaton library,role=external,window=_blank]
	is used for the evaluation of such patterns.

	[[operator_uploaderemail]]
	uploaderemail:'EMAIL_PATTERN'::
	+
	An operator that returns true if the change uploader's primary email address
	matches a specific regular expression pattern. The
	link:http://www.brics.dk/automaton/[dk.brics.automaton library,role=external,window=_blank]
	is used for the evaluation of such patterns.

	[[operator_distinctvoters]]
	distinctvoters:'[Label1,Label2,...,LabelN],value=MAX,count>1'::
	+
	An operator that allows checking for distinct voters across more than one label.
	+
	2..N labels are supported, filtering by a value (MIN,MAX,integer) is optional.
	Count is mandatory.
	+
	Examples:
	`distinctvoters:[Code-Review,Trust],value=MAX,count>1`
	+
	`distinctvoters:[Code-Review,Trust,API-Review],count>2`

	[[operator_is_true]]
	is:true::
	+
	An operator that always returns true for all changes. An example usage is to
	redefine a submit requirement in a child project and make the submit requirement
	always applicable.

	[[operator_is_false]]
	is:false::
	+
	An operator that always returns false for all changes. An example usage is to
	redefine a submit requirement in a child project and make the submit requirement
	always non-applicable.

	[[operator_has_submodule_update]]
	has:submodule-update::
	+
	An operator that returns true if the diff of the latest patchset against the
	default parent has a submodule modified file, that is, a ".gitmodules" or a
	git link file.
	+
	The optional `base` parameter can also be supplied for merge commits like
	`has:submodule-update,base=1`, or `has:submodule-update,base=2`. In these cases,
	the operator returns true if the diff of the latest patchset against parent
	number identified by `base` has a submodule modified file. Note that the
	operator will return false if the base parameter is greater than the number of
	parents for the latest patchset for the change.

	[[operator_file]]
	file:"'<filePattern>',withDiffContaining='<contentPattern>'"::
	+
	An operator that returns true if the latest patchset contained a modified file
	matching `<filePattern>` with a modified region matching `<contentPattern>`.
	+
	Both `<filePattern>` and `<contentPattern>` support regular expressions if they
	start with the '^' character. Regular expressions are matched with the
	`java.util.regex` engine. When using regular expressions, special characters
	should be double escaped because the config is parsed twice when the server
	reads the `project.config` file and when the submit-requirement expressions
	are parsed as a predicate tree. For example, to match against modified files
	that end with ".cc" or ".cpp" the following `applicableIf` expression can be
	used:
	+
	----
	applicableIf = file:\"^.*\\\\.(cc\|cpp)$\"
	----
	+
	Below is another example that uses both `<filePattern>` and `<contentPattern>`:
	+
	----
	applicableIf = file:\"'^.\\\\.(cc\|cpp)$',withDiffContaining='^.th[rR]ee$'\"
	----
	+
	If no regular expression is used, the text is matched by checking that the file
	name contains the file pattern, or the edits of the file diff contain the edit
	pattern.

	[[operator_label]]
	label:labelName=+1,user=non_contributor::
	+
	Submit requirements support an additional `user=non_contributor` argument for
	labels that returns true if the change has a label vote matching the specified
	value and the vote is applied from a gerrit account that's not the uploader,
	author or committer of the latest patchset. See the documentation for the labels
	operator in the link:user-search.html[user search] page.

	[[unsupported_operators]]
	=== Unsupported Operators

	Some operators are not supported with submit requirement expressions.

	[[operator_is_submittable]]
	is:submittable::
	+
	Cannot be used since it will result in recursive evaluation of expressions.

	[[inheritance]]
	== Inheritance

	Child projects can override a submit requirement defined in any of their parent
	projects. Overriding a submit requirement overrides all of its properties and
	values. The overriding project needs to define all mandatory fields.

	Submit requirements are looked up from the current project up the inheritance
	hierarchy to “All-Projects”. The first project in the hierarchy chain that sets
	link:#submit_requirement_can_override_in_child_projects[canOverrideInChildProjects]
	to false prevents all descendant projects from overriding it.

	If a project disallows a submit requirement from being overridden in child
	projects, all definitions of this submit requirement in descendant projects are
	ignored.

	To remove a submit requirement in a child project, administrators can redefine
	the requirement with the same name in the child project and set the
	link:#submit_requirement_applicable_if[applicableIf] expression to `is:false`.
	Since the link:#submit_requirement_submittable_if[submittableIf] field is
	mandatory, administrators need to provide it in the child project but can set it
	to anything, for example `is:false` but it will have no effect anyway.


	[[trigger-votes]]
	== Trigger Votes

	Trigger votes are label votes that are not associated with any submit
	requirement expressions. Trigger votes are displayed in a separate section in
	the change page. For more about configuring labels, see the
	link:config-labels.html[config labels] documentation.


	[[examples]]
	== Examples

	[[code-review-example]]
	=== Code-Review Example

	To define a submit requirement for code-review that requires a maximum vote for
	the “Code-Review” label from a non-uploader without a maximum negative vote:

	----
	[submit-requirement "Code-Review"]
	description = A maximum vote from a non-uploader is required for the \
	'Code-Review' label. A minimum vote is blocking.
	submittableIf = label:Code-Review=MAX,user=non_uploader AND -label:Code-Review=MIN
	canOverrideInChildProjects = true
	----

	[[exempt-branch-example]]
	=== Exempt a branch Example

	We could exempt a submit requirement from certain branches. For example,
	project owners might want to skip the 'Code-Style' requirement from the
	refs/meta/config branch.

	----
	[submit-requirement "Code-Style"]
	description = Code is properly styled and formatted
	applicableIf = -branch:refs/meta/config
	submittableIf = label:Code-Style=+1 AND -label:Code-Style=-1
	canOverrideInChildProjects = true
	----

	Branch configuration supports regular expressions as well, e.g. to exempt 'refs/heads/release/*' pattern,
	when migrating from the label Submit-Rule:

	----
	[label "Verified"]
	branch = refs/heads/release/*
	----

	The following SR can be configured:

	----
	[submit-requirement "Verified"]
	submittableIf = label:Verified=MAX AND -label:Verified=MIN
	applicableIf = branch:^refs/heads/release/.*
	----

	[[require-footer-example]]
	=== Require a footer Example

	It's possible to use a submit requirement to require a footer to be present in
	the commit message.

	----
	[submit-requirement "Bug-Footer"]
	description = Changes must include a 'Bug' footer
	applicableIf = -branch:refs/meta/config AND -hasfooter:\"Bug\"
	submittableIf = hasfooter:\"Bug\"
	----

	[[test-submit-requirements]]
	== Testing Submit Requirements

	The link:rest-api-changes.html#check-submit-requirement[Check Submit Requirement]
	change endpoint can be used to test submit requirements on any change. Users
	are encouraged to test submit requirements before adding them to the project
	to ensure they work as intended.

	.Request
	----
	POST /changes/myProject~master~I8473b95934b5732ac55d26311a706c9c2bde9940/check.submit_requirement HTTP/1.0
	Content-Type: application/json; charset=UTF-8

	{
	"name": "Code-Review",
	"submittability_expression": "label:Code-Review=+2"
	}
	----

	.Response
	----
	HTTP/1.1 200 OK
	Content-Disposition: attachment
	Content-Type: application/json; charset=UTF-8

	)]}'
	{
	"name": "Code-Review",
	"status": "SATISFIED",
	"submittability_expression_result": {
	"expression": "label:Code-Review=+2",
	"fulfilled": true,
	"passingAtoms": [
	"label:Code-Review=+2"
	]
	},
	"is_legacy": false
	}
	----

	GERRIT
	------
	Part of link:index.html[Gerrit Code Review]

	SEARCHBOX
	---------