Category: Devops

Posted on by — 1 Comment

Pass secrets as ENV variables on docker build – Azure devops

Sometimes you may need not to store your environmental variables on your Dockerfile as they could contain secret values. Especially when using source control you do not want to commit your .env files that they may contain secrets and other sensitive information.

Using the below procedure you can inject secret values as ENV variables on your Dockerfile during the build. Its important to know that you cannot use –env-file with docker build command as it be only used with docker run.

docker run | Docker Documentation

docker build | Docker Documentation

On docker build you can pass –build-arg values in order to set build-time variables. These values don’t persist in the intermediate or final images like ENV values do. You must add --build-arg for each build argument.

In my scenario I wanted to commit an ENV variable permanently on the image but I wanted to avoid storing this value on source control. In more details I wanted to have the APP_KEY as ENV variable inside the container.

The first step was to set this as a secret on the Azure Devops pipeline.

Then you will need to create an ARG definition on the Dockerfile which value will be taken from the Devops pipeline run. Then this value will be passed to the ENV variable APP_KEY. 

ARG APP_KEY
ENV APP_KEY=$APP_KEY

In the Docker command you will need to pass as –build-arg the values that you need (in my case APP_KEY)

    - task: Docker@2
      displayName: build docker image
      inputs:
        containerRegistry: 'registry'
        command: 'build'
        Dockerfile: '$(Pipeline.Workspace)/s/myapp/docker/Dockerfile'
        buildContext: '$(Pipeline.Workspace)/s/myapp'
        arguments: '-t image.azurecr.io/app-uat:${{parameters.dockertag}} --build-arg APP_KEY=$(APP_KEY)'
Posted on by — Leave a comment

Manual user approval for pipeline execution

In Azure DevOps pipelines you can use approvals in order to allow or not the deployment based on user input on a pipeline.

Find my article on how to create approvals on build and release pipelines below.

Create approvals on build and release Azure DevOps pipelines

But what happens if you want to run some tasks, get user input and then continue with some other tasks? For this reason you could use the Manual Validation task. As the name indicates, you can validate the user input and perform actions based on this input.

If you approve the execution then the pipeline will continue and if not the pipeline will stop.

You can then use the result of the previous job in order to perform other actions with succeeded() or failed() conditions.

An example of the Validation Task is shown below:

trigger:
- none

pool:
  vmImage: ubuntu-latest

jobs:
- job: job1
  pool: server
  steps:
  - task: ManualValidation@0
    inputs:
      notifyUsers: 'someone@kati.com'
      instructions: 'continue?'

- job: job2
  dependsOn: job1
  steps:
  - script: echo Hello, world!
    displayName: 'Run a one-line script'

The ManualValidation should be used mandatory with pool:server as shown above because it is an agentless job and cannot be run on the standard agent pools.

The job2 as it depends from job1 will run only if the approval is not rejected from the user.

Posted on by — Leave a comment

Change name for Azure devops pipeline

A common requirement when you work on your pipelines would be to name them according to your needs.

By default Azure devops name your pipeline with the buildID and the commit that initiated the build as shown below.

In order to change the name of the pipeline you can use the name keyword.

name: mypipeline

trigger:
- none

pool:
  vmImage: ubuntu-latest

steps:
- script: echo Hello, world!
  displayName: 'Run a one-line script'

Then you will have your custom name in the run of the pipeline.

Also from September 2022 and later, you can also remove the commit message from the title using appendCommitMessageToRunName

So by also adding this option

name: mypipeline
appendCommitMessageToRunName: false

trigger:
- none

pool:
  vmImage: ubuntu-latest

steps:
- script: echo Hello, world!
  displayName: 'Run a one-line script'

I will get only my preferred name on the pipeline run.

YouTube tutorial:

Posted on by — Leave a comment

Your branch is behind origin/main by 1 commit and can be fast-forwarded

Sometimes when you work on a repository you may have commited a change locally that is not pushed to the remote branch. As git is a collaborative platform other people may have commited in your branch and you may need to perform a git pull in order to get the latest changes.

Lets examine a common scenario on which you left behind your local branch. By executing git status we see that one commit that is performed on the local copy is not pushed.

The latest commit in the remote is the one with hash d82186bf6fbfdc8bb38ab5bd12b4bc170b550b7c

However the latest commit in the local repository (not in the same version as the remote) is the one shown below with the hash cd4a8c6f336fa5f7afad7d7d53d2555b7c87aabe and cannot be pulled because there are conflicts with my local commits.

When you have such conflicts you should define what you need to do. In my case I wanted to abort my local commit and get the latest version of the repository.

In order to do so 

git reset --hard origin/main

Then by getting the status and pulling you will verify that the latest commit is the one that is the most recent on the repository and your local changes have been discarded.