ConditionalApplyPlugin: Allow 'apply' on branches for specific environments

[boommies]

Use Case:
I want to be able to apply changes to non-production environments, without merging to master.

Example: I have 3 environments:

• qa
• uat
• prod

I want to be able to make a feature branch in git, and apply the changes from that branch to qa, before merging it into uat and prod.

Example Code:

@Library(['terraform-pipeline']) _

Jenkinsfile.init(this)

ConditionalApplyPlugin.withBranchApplyEnabledFor('qa').init()

def validate = new TerraformValidateStage()
def deployQa = new TerraformEnvironmentStage('qa')
def deployUat = new TerraformEnvironmentStage('uat')
def deployProd = new TerraformEnvironmentStage('prod')

validate.then(deployQa)
        .then(deployUat)
        .then(deployProd)
        .build()

Expected:

When I create a git branch and push a change, the pipeline will:

1. Run a terraform plan for 'qa'
2. Allow the user to apply the plan to 'qa'
3. Run a plan for 'uat' (DOES NOT allow apply for 'uat')
4. Run a plan for 'prod' (DOES NOT allow apply for 'uat')

[boommies]

Alternative to above:

When I create a git branch and push a change, the pipeline will:

1. Run a plan for 'qa'
2. Run a plan for 'uat'
3. Run a plan for 'prod'
4. Allow the user to apply the plan for 'qa' (only at the end)

This would give you the same feedback that you already get (the plans for qa, uat, prod), so that when you're prompted to apply the change to qa, you can make a more informed decision.

[ChrisBubelisCAI]

I like the first approach, with the subtle change that it is driven by the creation of a pull request and commits to that pull request branch.

[kmanning]

In hindsight, I think option 1 is the most easily implemented as well. Cool, let's set that as the goal for this issue.

[kmanning]

Bumping to a future release

[kmanning]

Bumping to a future release