# Rule structure reference Rule structure reference This section is a reference for rule configuration only. For a conceptual overview of the pipeline structure, see [CodePipeline pipeline structure reference](reference-pipeline-structure.md). Each rule provider in CodePipeline uses a set of required and optional configuration fields in the pipeline structure. This section provides the following reference information by rule provider: + Valid values for the `RuleType` fields included in the pipeline structure rule block, such as `Owner` and `Provider`. + Descriptions and other reference information for the `Configuration` parameters (required and optional) included in the pipeline structure rule section. + Valid example JSON and YAML rule configuration fields. Reference information is available for the following rule providers: **Topics** + [CloudWatchAlarm](rule-reference-CloudWatchAlarm.md) + [CodeBuild rule](rule-reference-CodeBuild.md) + [Commands](rule-reference-Commands.md) + [DeploymentWindow](rule-reference-DeploymentWindow.md) + [LambdaInvoke](rule-reference-LambdaInvoke.md) + [VariableCheck](rule-reference-VariableCheck.md) # CloudWatchAlarm CloudWatchAlarm When you create a condition, you can add the `CloudWatchAlarm` rule. This section provides a reference for the rule parameters. For more information about rules and conditions, see [How do stage conditions work?](concepts-how-it-works-conditions.md). You must have already created an alarm in Amazon CloudWatch as a separate resource. **Topics** + [ ## Rule type ](#rule-reference-CloudWatchAlarm-type) + [ ## Configuration parameters ](#rule-reference-CloudWatchAlarm-config) + [ ## Example rule configuration ](#rule-reference-CloudWatchAlarm-example) + [ ## See also ](#rule-reference-CloudWatchAlarm-links) ## Rule type + Category: `Rule` + Owner: `AWS` + Provider: `CloudWatchAlarm` + Version: `1` ## Configuration parameters **AlarmName** Required: Yes The name of the CloudWatch alarm. This is a separate resource created in CloudWatch. **AlarmStates** Required: No The desired CloudWatch alarm states for the rule to monitor. Valid values are ALARM, OK, and INSUFFICIENT\$1DATA. **WaitTime** Required: No The wait time in minutes to allow for a state change before running the rule result. For example, configure 20 minutes to wait for an alarm state to change to OK before applying the rule result. ## Example rule configuration ------ #### [ YAML ] ``` rules: - name: MyMonitorRule ruleTypeId: category: Rule owner: AWS provider: CloudWatchAlarm version: '1' configuration: AlarmName: CWAlarm WaitTime: '1' inputArtifacts: [] region: us-east-1 ``` ------ #### [ JSON ] ``` "rules": [ { "name": "MyMonitorRule", "ruleTypeId": { "category": "Rule", "owner": "AWS", "provider": "CloudWatchAlarm", "version": "1" }, "configuration": { "AlarmName": "CWAlarm", "WaitTime": "1" }, "inputArtifacts": [], "region": "us-east-1" } ] } ``` ------ ## See also The following related resources can help you as you work with this rule. + [Creating On Failure conditions](stage-conditions.md#stage-conditions-onfailure) – This section provides steps for creating an On Failure condition with an alarm rule. # CodeBuild rule CodeBuild rule When you create a condition, you can add the CodeBuild rule. This section provides a reference for the rule parameters. For more information about rules and conditions, see [How do stage conditions work?](concepts-how-it-works-conditions.md). You can use the CodeBuild rule to create a condition where the succesful run of your build project meets the rule criteria, such as the build run being successful for a beforeEntry condition. **Note** For beforeEntry conditions that are configured with the **Skip** result, only the following rules are available: `LambdaInvoke` and `VariableCheck`. **Topics** + [ ## Service role policy permissions ](#rule-reference-Commands-policy) + [ ## Rule type ](#rule-reference-Commands-type) + [ ## Configuration parameters ](#rule-reference-Commands-config) + [ ## Example rule configuration ](#rule-reference-Commands-example) + [ ## See also ](#rule-reference-Commands-links) ## Service role policy permissions For permissions for this rule, add the following to your CodePipeline service role policy statement. Scope down permissions to the resource level. ``` { "Effect": "Allow", "Action": [ "codebuild:BatchGetBuilds", "codebuild:StartBuild" ], "Resource": "resource_ARN" }, ``` ## Rule type + Category: `Rule` + Owner: `AWS` + Provider: `CodeBuild` + Version: `1` ## Configuration parameters **ProjectName** Required: Yes `ProjectName` is the name of the build project in CodeBuild. **PrimarySource** Required: Conditional The value of the `PrimarySource` parameter must be the name of one of the input artifacts to the action. CodeBuild looks for the buildspec file and runs the buildspec commands in the directory that contains the unzipped version of this artifact. This parameter is required if multiple input artifacts are specified for a CodeBuild action. When there is only one source artifact for the action, the `PrimarySource` artifact defaults to that artifact. **BatchEnabled** Required: No The Boolean value of the `BatchEnabled` parameter allows the action to run multiple builds in the same build execution. When this option is enabled, the `CombineArtifacts` option is available. For pipeline examples with batch builds enabled, see [CodePipeline integration with CodeBuild and batch builds](https://docs.aws.amazon.com/codebuild/latest/userguide/sample-pipeline-batch.html). **CombineArtifacts** Required: No The Boolean value of the `CombineArtifacts` parameter combines all build artifacts from a batch build into a single artifact file for the build action. To use this option, the `BatchEnabled` parameter must be enabled. **EnvironmentVariables** Required: No The value of this parameter is used to set environment variables for the CodeBuild action in your pipeline. The value for the `EnvironmentVariables` parameter takes the form of a JSON array of environment variable objects. See the example parameter in [Action declaration (CodeBuild example)](action-reference-CodeBuild.md#action-reference-CodeBuild-example). Each object has three parts, all of which are strings: + `name`: The name or key of the environment variable. + `value`: The value of the environment variable. When using the `PARAMETER_STORE` or `SECRETS_MANAGER` type, this value must be the name of a parameter you have already stored in AWS Systems Manager Parameter Store or a secret you have already stored in AWS Secrets Manager, respectively. **Note** We strongly discourage the use of environment variables to store sensitive values, especially AWS credentials. When you use the CodeBuild console or AWS CLI, environment variables are displayed in plain text. For sensitive values, we recommend that you use the `SECRETS_MANAGER` type instead. + `type`: (Optional) The type of environment variable. Valid values are `PARAMETER_STORE`, `SECRETS_MANAGER`, or `PLAINTEXT`. When not specified, this defaults to `PLAINTEXT`. When you enter the `name`, `value`, and `type` for your environment variables configuration, especially if the environment variable contains CodePipeline output variable syntax, do not exceed the 1000-character limit for the configuration’s value field. A validation error is returned when this limit is exceeded. For more information, see [ EnvironmentVariable](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_EnvironmentVariable.html) in the AWS CodeBuild API Reference. For an example CodeBuild action with an environment variable that resolves to the GitHub branch name, see [Example: Use a BranchName variable with CodeBuild environment variables](actions-variables.md#actions-variables-examples-env-branchname). ## Example rule configuration ------ #### [ YAML ] ``` name: codebuild-rule ruleTypeId: category: Rule owner: AWS provider: CodeBuild version: '1' configuration: ProjectName: my-buildproject EnvironmentVariables: '[{"name":"VAR1","value":"variable","type":"PLAINTEXT"}]' inputArtifacts: - name: SourceArtifact region: us-east-1 ``` ------ #### [ JSON ] ``` { "name": "codebuild-rule", "ruleTypeId": { "category": "Rule", "owner": "AWS", "provider": "CodeBuild", "version": "1" }, "configuration": { "ProjectName": "my-buildproject" }, "inputArtifacts": [ { "name": "SourceArtifact", "EnvironmentVariables": "[{\"name\":\"VAR1\",\"value\":\"variable\",\"type\":\"PLAINTEXT\"}]" } ], "region": "us-east-1" } ``` ------ ## See also The following related resources can help you as you work with this rule. + For more information about rules and conditions, see [Condition](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_Condition.html), [RuleTypeId](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_RuleTypeId.html), and [RuleExecution](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_RuleExecution.html) in the *CodePipeline API Guide*. # Commands Commands When you create a condition, you can add the `Commands` rule. This section provides a reference for the rule parameters. For more information about rules and conditions, see [How do stage conditions work?](concepts-how-it-works-conditions.md). You can use the `Commands` rule to create a condition where the succesful commands meet the rule criteria, such as the output and file path for the commands being successful for a beforeEntry condition. **Note** For beforeEntry conditions that are configured with the **Skip** result, only the following rules are available: `LambdaInvoke` and `VariableCheck`. **Topics** + [ ## Considerations for the Commands rule ](#rule-reference-Commands-considerations) + [ ## Service role policy permissions ](#rule-reference-Commands-policy) + [ ## Rule type ](#rule-reference-Commands-type) + [ ## Configuration parameters ](#rule-reference-Commands-config) + [ ## Example rule configuration ](#rule-reference-Commands-example) + [ ## See also ](#rule-reference-Commands-links) ## Considerations for the Commands rule The following considerations apply for the Commands rule. + The commands rule uses CodeBuild resources similar to the CodeBuild action, while allowing shell environment commands in a virtual compute instance without the need to associate or create a build project. **Note** Running the commands rule will incur separate charges in AWS CodeBuild. + Because the Commands rule in CodePipeline uses CodeBuild resources, the builds run by the action will be attributed to the build limits for your account in CodeBuild. Builds run by the Commands rule will count toward the concurrent build limits as configured for that account. + The timeout for builds with the Commands rule is 55 minutes, as based on CodeBuild builds. + The compute instance uses an isolated build environment in CodeBuild. **Note** Because the isolated build environment is used at the account level, an instance might be reused for another pipeline execution. + All formats are supported except multi-line formats. You must use single-line format when entering commands. + For this rule, CodePipeline will assume the pipeline service role and use that role to allow access to resources at runtime. It is recommended to configure the service role so that the permissions are scoped down to the action level. + The permissions added to the CodePipeline service role are detailed in [Add permissions to the CodePipeline service role](how-to-custom-role.md#how-to-update-role-new-services). + The permission needed to view logs in the console is detailed in [Permissions required to view compute logs in the console](security-iam-permissions-console-logs.md) . In the following example screens, use the **Logs** link to view logs for a successful Commands rule in CloudWatch logs. ![\[The Status page for a pipeline with the Commands rule\]](http://docs.aws.amazon.com/codepipeline/latest/userguide/images/commands-rule-status.png) ![\[The Logs page in CloudWatch for a pipeline with the Commands rule\]](http://docs.aws.amazon.com/codepipeline/latest/userguide/images/commands-rule-logs.png) + Unlike other actions in CodePipeline, you do not set fields in the action configuration; you set the action configuration fields outside of the action configuration. ## Service role policy permissions When CodePipeline runs the rule, CodePipeline creates a log group using the name of the pipeline as follows. This enables you to scope down permissions to log resources using the pipeline name. ``` /aws/codepipeline/MyPipelineName ``` If you are using an existing service role, to use the Commands action, you will need to add the following permissions for the service role. + logs:CreateLogGroup + logs:CreateLogStream + logs:PutLogEvents In the service role policy statement, scope down the permissions to the pipeline level as shown in the following example. ``` { "Effect": "Allow", "Action": [ "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents" ], "Resource": "arn:aws:logs:*:YOUR_AWS_ACCOUNT_ID:log-group:/aws/codepipeline/YOUR_PIPELINE_NAME:*" } ``` To view logs in the console using the action details dialog page, the permission to view logs must be added to the console role. For more information, see the console permissions policy example in [Permissions required to view compute logs in the console](security-iam-permissions-console-logs.md). ## Rule type + Category: `Rule` + Owner: `AWS` + Provider: `Commands` + Version: `1` ## Configuration parameters **Commands** Required: Yes You can provide shell commands for the `Commands` rule to run. In the console, commands are entered on separate lines. In the CLI, commands are entered as separate strings. Multi-line formats are not supported and will result in an error message. Single-line format must be used for entering commands in the **Commands** field. The following details provide the default compute that is used for the Commands rule. For more information, see [Build environment compute modes and types](https://docs.aws.amazon.com/codebuild/latest/userguide/build-env-ref-compute-types.html) reference in the CodeBuild User Guide. + **CodeBuild image:** aws/codebuild/amazonlinux2-x86\$164-standard:5.0 + **Compute type:** Linux Small + **Environment computeType value: **BUILD\$1GENERAL1\$1SMALL + **Environment type value:** LINUX\$1CONTAINER ## Example rule configuration ------ #### [ YAML ] ``` result: FAIL rules: - name: CommandsRule ruleTypeId: category: Rule owner: AWS provider: Commands version: '1' configuration: {} commands: - ls - printenv inputArtifacts: - name: SourceArtifact region: us-east-1 ``` ------ #### [ JSON ] ``` { "result": "FAIL", "rules": [ { "name": "CommandsRule", "ruleTypeId": { "category": "Rule", "owner": "AWS", "provider": "Commands", "version": "1" }, "configuration": {}, "commands": [ "ls", "printenv" ], "inputArtifacts": [ { "name": "SourceArtifact" } ], "region": "us-east-1" } ] } ``` ------ ## See also The following related resources can help you as you work with this rule. + For more information about rules and conditions, see [Condition](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_Condition.html), [RuleTypeId](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_RuleTypeId.html), and [RuleExecution](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_RuleExecution.html) in the *CodePipeline API Guide*. # DeploymentWindow DeploymentWindow When you create a condition, you can add the `DeploymentWindow` rule. This section provides a reference for the rule parameters. For more information about rules and conditions, see [How do stage conditions work?](concepts-how-it-works-conditions.md). **Topics** + [ ## Rule type ](#rule-reference-DeploymentWindow-type) + [ ## Configuration parameters ](#rule-reference-DeploymentWindow-config) + [ ## Example rule configuration ](#rule-reference-DeploymentWindow-example) + [ ## See also ](#rule-reference-DeploymentWindow-links) ## Rule type + Category: `Rule` + Owner: `AWS` + Provider: `DeploymentWindow` + Version: `1` ## Configuration parameters **Cron** Required: Yes The expression that defines the days and times when the deployment will be allowed. Cron expressions are comprised of 6 required fields and one optional field separated by white space. The cron expression fields allow you to specify a schedule pattern with a cron expression as follows. **** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/codepipeline/latest/userguide/rule-reference-DeploymentWindow.html) + The '\$1' character is used to specify all values. For example, "\$1" in the minute field means "every minute". + The '?' character is allowed for the day-of-month and day-of-week fields. It is used to specify 'no specific value'. This is useful when you need to specify something in one of the two fields, but not the other. + The '-' character is used to specify ranges For example "10-12" in the hour field means "the hours 10, 11 and 12". + The ',' character is used to specify additional values. For example "MON,WED,FRI" in the day-of-week field means "the days Monday, Wednesday, and Friday". + The '/' character is used to specify increments. For example "0/15" in the seconds field means "the seconds 0, 15, 30, and 45". And "5/15" in the seconds field means "the seconds 5, 20, 35, and 50". Specifying '\$1' before the '/' is equivalent to specifying 0 is the value to start with. + The 'L' character is allowed for the day-of-month and day-of-week fields. This character is short-hand for "last", but it has different meaning in each of the two fields. For example, the value "L" in the day-of-month field means "the last day of the month" - day 31 for January, day 28 for February on non-leap years. If used in the day-of-week field by itself, it simply means "7" or "SAT". But if used in the day-of-week field after another value, it means "the last day of the month" - for example "6L" means "the last friday of the month". You can also specify an offset from the last day of the month, such as "L-3" which would mean the third-to-last day of the calendar month. + The 'W' character is allowed for the day-of-month field. This character is used to specify the weekday (Monday-Friday) nearest the given day. As an example, if you were to specify "15W" as the value for the day-of-month field, the meaning is: "the nearest weekday to the 15th of the month". So if the 15th is a Saturday, the trigger will fire on Friday the 14th. If the 15th is a Sunday, the trigger will fire on Monday the 16th. If the 15th is a Tuesday, then it will fire on Tuesday the 15th. + The 'L' and 'W' characters can also be combined for the day-of-month expression to yield 'LW', which translates to "last weekday of the month". + The '\$1' character is allowed for the day-of-week field. This character is used to specify "the nth" day of the month. For example, the value of "6\$13" in the day-of-week field means the third Friday of the month (day 6 = Friday and "\$13" = the 3rd one in the month). + The legal characters and the names of months and days of the week are not case sensitive. **TimeZone** Required: No The time zone for the deployment window. The regular expression matches patterns in the following formats: + **Region/City format**. The value matches a time zone in the format Region/City or Region/City\$1City. For example, `America/New_York` or `Europe/Berlin`. + **UTC format**. The value matches the string UTC optionally followed by an offset in the format \$1HH:MM or -HH:MM. For example, `UTC`, `UTC+05:30`, or `UTC-03:00`. This is the default format if the parameter is not set otherwise. + **Abbreviation format**. The value matches a 3 to 5 character abbreviation for a time zone. For example, `EST` or `IST`. For a table of valid TimeZoneID values, see [https://docs.oracle.com/middleware/1221/wcs/tag-ref/MISC/TimeZones.html](https://docs.oracle.com/middleware/1221/wcs/tag-ref/MISC/TimeZones.html). Note that certain abbreviations are duplicated abbreviations, such as CST for Central Standard Time, China Standard Time, and Cuba Standard Time. ## Example rule configuration ------ #### [ YAML ] ``` - name: MyDeploymentRule ruleTypeId: category: Rule owner: AWS provider: DeploymentWindow version: '1' configuration: Cron: 0 0 9-17 ? * MON-FRI * TimeZone: PST inputArtifacts: [] region: us-east-1 ``` ------ #### [ JSON ] ``` [ { "name": "MyDeploymentRule", "ruleTypeId": { "category": "Rule", "owner": "AWS", "provider": "DeploymentWindow", "version": "1" }, "configuration": { "Cron": "0 0 9-17 ? * MON-FRI *", "TimeZone": "PST" }, "inputArtifacts": [], "region": "us-east-1" } ] ``` ------ ## See also The following related resources can help you as you work with this rule. + [Creating On Success conditions](stage-conditions.md#stage-conditions-onsuccess) – This section provides steps for creating an On Success condition with a deployment window rule. + For more information about rules and conditions, see [Condition](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_Condition.html), [RuleTypeId](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_RuleTypeId.html), and [RuleExecution](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_RuleExecution.html) in the *CodePipeline API Guide*. # LambdaInvoke LambdaInvoke When you create a condition, you can add the `LambdaInvoke` rule. This section provides a reference for the rule parameters. For more information about rules and conditions, see [How do stage conditions work?](concepts-how-it-works-conditions.md). You must have already created a function in Lambda as a separate resource. **Topics** + [ ## Rule type ](#rule-reference-CloudWatchAlarm-type) + [ ## Configuration parameters ](#rule-reference-LambdaInvoke-config) + [ ## Example rule configuration ](#rule-reference-LambdaInvoke-example) + [ ## See also ](#rule-reference-LambdaInvoke-links) ## Rule type + Category: `Rule` + Owner: `AWS` + Provider: `LambdaInvoke` + Version: `1` ## Configuration parameters **FunctionName** Required: Yes The name of the Lambda function. **UserParameters** Required: No These are parameters that are provided as input for the function in key-value pair format. ## Example rule configuration ------ #### [ YAML ] ``` - name: MyLambdaRule ruleTypeId: category: Rule owner: AWS provider: LambdaInvoke version: '1' configuration: FunctionName: my-function inputArtifacts: - name: SourceArtifact region: us-east-1 ``` ------ #### [ JSON ] ``` [ { "name": "MyLambdaRule", "ruleTypeId": { "category": "Rule", "owner": "AWS", "provider": "LambdaInvoke", "version": "1" }, "configuration": { "FunctionName": "my-function" }, "inputArtifacts": [ { "name": "SourceArtifact" } ], "region": "us-east-1" } ] ``` ------ ## See also The following related resources can help you as you work with this rule. + [Creating On Failure conditions](stage-conditions.md#stage-conditions-onfailure) – This section provides steps for creating an On Failure condition with an alarm rule. # VariableCheck VariableCheck When you create a condition, you can add the `VariableCheck` rule. This section provides a reference for the rule parameters. For more information about rules and conditions, see [How do stage conditions work?](concepts-how-it-works-conditions.md). You can use the `VariableCheck` rule to create a condition where the output variable is checked against a provided expression. The rule passes the check when the variable value meets the rule criteria, such as the value being equal or greater than a specified output variable. **Topics** + [ ## Rule type ](#rule-reference-VariableCheck-type) + [ ## Configuration parameters ](#rule-reference-VariableCheck-config) + [ ## Example rule configuration ](#rule-reference-VariableCheck-example) + [ ## See also ](#rule-reference-VariableCheck-links) ## Rule type + Category: `Rule` + Owner: `AWS` + Provider: `VariableCheck` + Version: `1` ## Configuration parameters **Operator** Required: Yes The operator that indicates which operation to perform for the variable check. In the following example, the output variable for the repository name will be checked for whether it is equal to `MyDemoRepo`. ``` "configuration": { "Variable": "#{SourceVariables.RepositoryName}", "Value": "MyDemoRepo", "Operator": "EQ" }, ``` The following operators are available to create an expression as follows. + **Equals** - Choose this operator to check whether the variable is equal to the string value. **CLI parameter:** `EQ` + **Contains** - Choose this operator to check whether the variable contains the string value as a substring. **CLI parameter:** `CONTAINS` + **Matches** - Choose this operator to check whether the variable matches a given regex expression as the string value. All regular expressions in CodePipeline conform to the Java regex syntax. For a comprehensive description of the Java regex syntax and its constructs, see [java.util.regex.Pattern](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/regex/Pattern.html). **CLI parameter:** `MATCHES` + **Not equals** - Choose this operator to check whether the variable is not equal to the string value. **CLI parameter:** `NE` **Variable** Required: Yes The pipeline variables to check. **Value** Required: Yes The value for the expression to check against. In the following example, the output variable for the repository name will be checked for whether it is equal to `MyDemoRepo`. ``` "configuration": { "Variable": "#{SourceVariables.RepositoryName}", "Value": "MyDemoRepo", "Operator": "EQ" }, ``` In the following JSON example, two separate rules are defined, one for an `EQ` (equals) statement that checks the repository and branch name formatted as \$1\$1SourceVariables.RepositoryName\$1 and one for `CONTAINS` that checks the commit message output variable formatted as \$1\$1SourceVariables.CommitMessage\$1 against the provided value "update." ``` "beforeEntry": { "conditions": [ { "result": "FAIL", "rules": [ { "name": "MyVarCheckRule", "ruleTypeId": { "category": "Rule", "owner": "AWS", "provider": "VariableCheck", "version": "1" }, "configuration": { "Operator": "EQ", "Value": "MyDemoRepo", "Variable": "#{SourceVariables.RepositoryName}" }, "inputArtifacts": [], "region": "us-east-1" }, { "name": "MyVarCheckRuleContains", "ruleTypeId": { "category": "Rule", "owner": "AWS", "provider": "VariableCheck", "version": "1" }, "configuration": { "Operator": "CONTAINS", "Value": "update", "Variable": "#{SourceVariables.CommitMessage}" }, "inputArtifacts": [], "region": "us-east-1" } ] } ] } } ], ``` ## Example rule configuration ------ #### [ YAML ] ``` - name: MyVariableCheck ruleTypeId: category: Rule owner: AWS provider: VariableCheck version: '1' configuration: Variable: "#{SourceVariables.RepositoryName}" Value: MyDemoRepo Operator: EQ inputArtifacts: [] region: us-west-2 ``` ------ #### [ JSON ] ``` "rules": [ { "name": "MyVariableCheck", "ruleTypeId": { "category": "Rule", "owner": "AWS", "provider": "VariableCheck", "version": "1" }, "configuration": { "Variable": "#{SourceVariables.RepositoryName}", "Value": "MyDemoRepo", "Operator": "EQ" }, "inputArtifacts": [], "region": "us-west-2" } ] ``` ------ ## See also The following related resources can help you as you work with this rule. + [Tutorial: Create a variable check rule for a pipeline as an entry condition](tutorials-varcheckrule.md) – This section provides a tutorial with steps for creating an On Entry condition with a variable check rule. + [Variables reference](reference-variables.md) – This section provides reference information and examples for pipeline variables. + For more information about rules and conditions, see [Condition](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_Condition.html), [RuleTypeId](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_RuleTypeId.html), and [RuleExecution](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_RuleExecution.html) in the *CodePipeline API Guide*.