Reusing CI/CD components for Azure Bicep deployments

Table of contents:

The GitLab’s CI/CD Catalog became recently generally available and therefore it’s time to build and share something useful and reusable for the community.

What are components? #

Components allow you to define reusable building blocks for your pipelines. They abstract away complexity and make pipelines more modular. Define a build component that can be reused across pipelines.

At the time of writing this article only template-type components available (there is CI steps coming up next). This article is about template-type components.

How to access CI/CD Catalog components #

The link.

To share components with community one can follow this example.

Component usage #

In order to use componet we need to include component’s project and pass version of component (or main) like this:

1include:
2  - component: $CI_SERVER_FQDN/gitlab-cicd-component/gitlab-cicd-component-azure-bicep/azure-bicep@0.0.1

Inputs #

Promoting Flexibility: Replacing Hardcoded Values with Inputs!

When creating CI/CD components, it’s crucial to avoid hardcoding values, as this can limit the component’s reusability and force users to review and adapt the component’s internal details to work with their pipelines.

The Pitfalls of Hardcoded Values

One common area where hardcoded values can cause issues is the stage keyword. If a component job’s stage is hardcoded, all pipelines using the component must either define the exact same stage or override the configuration, leading to potential conflicts and maintenance challenges.

Embracing Dynamic Configuration with Inputs

To promote flexibility and ease of use, the preferred approach is to leverage the input keyword for dynamic component configuration. This allows component users to specify the exact values they need, tailoring the component to their specific requirements.

For example, to create a component with a configurable stage, you can use the following structure:

 1# Component definition
 2.my-component:
 3  stage: 
 4    ${{ inputs.stage }}
 5  script:
 6    - echo "Running in stage $CI_JOB_STAGE"
 7
 8# Pipeline configuration
 9my-job:
10  extends: .my-component
11  inputs:
12    stage: build

In this example, the component’s stage is defined using the ${{ inputs.stage }} syntax, allowing the pipeline configuration to specify the desired stage value (build in this case) through the inputs keyword.

Azure Bicep CICD component #

The component’s URL, it’s source code.

The goal is to extend this article by providing easy way to build, test and deploy Azure Bicep templates by passing main template to the pipeline that knows what to do with it further. Let’s take a look at the jobs:

• bicep2arm - this job turns bicep’s template into it’s ARM equivalent so that we can use IAC scan (GitLab Uses KICS by CheckMarx)
• kics-iac-sast - the SAST for IAC that evaluate templates and it’s arguments againts the following queries.
• lint - Bicep linter that checks Bicep files for syntax errors and best practice violations. The linter helps enforce coding standards by providing guidance during development. You can customize the best practices to use for checking the file.
• validate - Validate whether a template is valid at subscription scope.
• what-if - Azure Resource Manager provides the what-if operation to let you see how resources will change if you deploy the Bicep file.
• deploy - Creates deployment stack
• destroy - Deletes deployment stack

NB! Template uses mix of deployment stacks and deployment sub-commands of az-cli.

How to use #

1
2include:
3  - component: $CI_SERVER_FQDN/gitlab-cicd-component/gitlab-cicd-component-azure-bicep/azure-bicep@0.0.1

The component expects some inputs, for example:

 1
 2include:
 3  # include the component located in the current project from the current SHA
 4  - component: $CI_SERVER_FQDN/gitlab-cicd-component/gitlab-cicd-component-azure-bicep/azure-bicep@main
 5    inputs:
 6      azure-cli-image: mcr.microsoft.com/azure-cli
 7      azure-tenant-id: $AZURE_TENANT_ID
 8      azure-subscription-id: $AZURE_SUBSCRIPTION_ID
 9      azure-app-id: $AZURE_APP_ID
10      azure-password: $AZURE_PASSWORD
11      azure-bicep-template-location: ./landing-zone
12      azure-bicep-template-main-file: main.bicep
13      resource-group: azure-bicep-gitlab

azure-bicep-template-location and azure-bicep-template-main-file are “the entry” points to the Bicep template that needs to be deployed!

Just add some spinach your inputs and happy Bicep! :D