Constructing pipelines in the web UI

Build and manage pipelines for your control repo or module in the Continuous Delivery for Puppet Enterprise (PE) web UI using the tools built into the interface. If you complete the tasks on this page in the order presented, you'll set up and learn to use a basic pipeline.

Create a pipeline

Set up a pipeline to enable automatic testing of newly added code by adding stages and jobs in the Continuous Delivery for PE web UI.

  1. In the Continuous Delivery for PE web UI, click Control repos. Click the name of the control repo you wish to set up a pipeline for.

    Continuous Delivery for PE automatically creates a pipeline for the branch you selected when setting up the control repo (the master branch). You'll see this branch name at the top of the Pipelines area of the web UI.

    Tip: You can also set up pipelines for other branches in this repo, in order to automatically run tests on the code changes that Continuous Delivery for PE makes on your behalf. To create a pipeline for a different branch, click Add pipeline . You can undo this action with Delete pipeline .
  2. Every pipeline needs at least one stage. Click + Add stage and select Jobs.
  3. Select a job from the list, and click Add stage. Your job is added to the pipeline. Click Done.

    If you need to run a single test on your new code, your pipeline can be this simple. But if you wish to add additional tests, you can either add them to the existing stage by clicking Add job, or create another stage.

  4. Create a second stage in your pipeline by clicking Add another stage and selecting Job. Select a job from the list and click Add stage, then Done.
    Tip: If you wish to remove or reorder the stages in your pipeline, click More actions . To delete all stages in a pipeline and start fresh, click Delete pipeline .
  5. You now have a two-stage pipeline with a promotion step between the stages. Select Auto promote and choose a promotion condition from the options.
    The promotion condition you select tells the pipeline what to do at the end of the pipeline stage. The available permission conditions, listed from most to least restrictive, are:
    • All succeeded: The pipeline moves on to the next stage only if all the steps in the current stage finish with a "succeeded" or "done" status.
    • All completed: The pipeline moves on to the next stage if all the steps in the current stage finish with a "succeeded," "done," or "failed" status. The pipeline does not move on if any step in the current stage is canceled.
    • Any succeeded: The pipeline moves on to the next stage if at least one of the steps in the current stage finishes with a "succeeded" or "done" status.
    • Any completed: The pipeline moves on to the next stage if at least one of the steps in the current stage finishes with a "succeeded," "done," or "failed" status. The pipeline does not move on if all steps in the current stage are canceled.
Results

Your pipeline is ready for use.

Create a regex branch pipeline

Most pipelines are associated with a single branch in your control repo or module repo. A regex branch pipeline is configured to recognize and act on changes to any branch on your control repo or module repo that has a name matching the regular expression you set.

A regex branch pipeline lets you use a single pipeline for all the feature branches you and your team create and destroy in the process of developing new code. When you create a commit or pull request to a feature branch whose name uses the naming convention you've established for your regex branch pipeline, Continuous Delivery for PE automatically runs the regex pipeline.

  1. In the Continuous Delivery for PE web UI, navigate to a control repo or module repo.
  2. Click Add pipeline .
  3. In the Add pipeline window, select Branch regex.
    Only one regex branch pipeline can be created for each module repo or control repo. If you don't see the option to select Branch regex at the top of the window, a regex branch pipeline already exists for this repo.
  4. Enter the regular expression that your regex branch pipeline will use to recognize feature branches that should trigger pipeline runs. The default regular expression is feature_.*. If you use the default regex, your feature branches must use a feature_<BRANCHNAME> naming convention.
    Tip: All members of your team must use this naming convention when creating feature branches in order for their changes to trigger the regex branch pipeline. We strongly recommend using the default regular expression or one that's similarly simple and memorable.
  5. Click Add pipeline. The regex branch pipeline is created.
  6. Optional. To adjust the settings for your regex branch pipeline, click Manage pipelines. On this screen, you can set whether your regex branch pipeline will be triggered by commits, pull requests, or both.
  7. Build out your pipeline by adding jobs, impact analysis tasks, and deployments.
Results
You now have a pipeline configured to run in response to trigger conditions on any branch named with the naming convention you've selected.

Test code automatically with a pipeline

Every time you commit new code to your development or master branch, the pipeline runs the jobs you've set up to test the code and reports any errors or failures.

  1. To see the pipeline in action, make a trivial change (such as adding a new line to the README file) in the master branch of your control repo. Commit your change.
  2. In the Continuous Delivery for PE web UI, click Control repos, then click the name of the control repo you just committed code to.
  3. The Events area now shows you the push event initiated by your code commit, and an entry for each job in your pipeline. The jobs report their status here, and update to show their success or failure when the job run is complete.

    Each event summary includes a link to the commit in the control repo. Job events also include a job number; clicking on this number takes you to the Job details page, where you can see the job's log for its run and review error messages.

Test pull requests automatically

When "pull request" is enabled as a pipeline trigger, your pipeline automatically tests new code each time a pull request is opened against the relevant branch. By setting up a PR gate in the pipeline, you can ensure that the relevant tests run on the new code, but stop the pipeline before it proceeds to further tests or a deployment.

Note: If you're a GitLab user, you might be more familiar with the term "merge request" than "pull request." Although the two terms refer to the same concept and can be used interchangeably, for the sake of simplicity and consistency, the Continuous Delivery for PE web UI and these instructions use the term "pull request" (PR).
  1. Add a pull request (PR) gate to your pipeline. A PR gate indicates that any pipeline runs triggered by a pull request stops at a certain point in the pipeline. This allows you to automatically run acceptance tests on new pull requests, but to manage additional testing or deployment of the new code manually based on the results of the initial automated tests.
    1. In your pipeline's first stage, click More actions . Click Add item to stage, and select Pull request gate.
    2. Click Add PR gate. When the gate has been added, you'll see a success message. Click Done.
      Important: You can add only one PR gate to a pipeline. If you decide to move the placement of a PR gate, delete the existing gate and create a new one in the desired stage.
  2. To see the PR gate in action, switch to a branch in your control repo other than master. Make a trivial change (such as adding a new line to the README file) in your control repo, and commit your change, then open a pull request against the master branch for this commit.
    Remember: The pull request must be made against the branch the pipeline is set up to use in order to trigger the pipeline.
  3. In the Continuous Delivery for PE web UI, click Control repos, then click the name of the control repo you just committed code to.
  4. The Events area now shows you the pull request event initiated by your code commit, and an entry for the job in your pipeline that precedes the PR gate. Note that the job in the pipeline's second stage, beyond the PR gate, has not been triggered.

Deploy code automatically with a pipeline

You can use a control repo pipeline to automatically deploy new code to a specified set of nodes every time a commit is made.

  1. In the Continuous Delivery for PE web UI, click Control repos. Click the name of the control repo you've created a pipeline for.
  2. Click + Add stage.
  3. In the Add new stage window, select Deployment.
  4. Select your Puppet Enterprise instance and the node group you wish to deploy changes to every time this pipeline runs.
  5. Select a deployment policy. For purposes of this getting started guide, select Direct deployment policy.

    See Deployment policies to learn more about the four deployment policies and how they work.

  6. Optional: Set termination conditions for this pipeline's deployments, and choose the number of nodes that can fail before the deployment is stopped.
  7. Click Add Stage and close the Add new stage window. Your new stage, showing the details of the deployment, is added to the pipeline.
  8. To see the pipeline in action, make a trivial change (such as adding a new line to the README file) on the master branch of your control repo. Commit your change.

    The control repo Events area now shows you the push event initiated by your code commit, and a deployment event. The deployment reports its status here, and updates to show its success or failure when the deployment is complete.

    Each event summary includes a link to the commit in the control repo. Deployment events also include a deployment number; clicking on this number takes you to the deployment's details page, where you can see more information.

  9. You can run the same deployment again from the web UI by retriggering the webhook. In the Events area, locate the push event you wish to rerun, and click View webhook.

    The webhook's request and response data is shown in the Webhook data pane, which can be useful for troubleshooting.

  10. Click Redeliver webhook, and confirm your action. The Events area now shows the new event triggered by the redelivery of the webhook.
    Note: If you've made changes to your pipeline since the last time this webhook was delivered, the redelivered webhook follows the current pipeline's sequence and rules.