Tag: azuredevops

Posted on by — Leave a comment

Azure DevOps best practices – Organization security settings

Security is a vital component of every Organization. As such DevOps components and environments should also be protected and created based on best practices. Below are some important settings that you should consider enabling/disabling for your Azure DevOps Organization. All these can be found on the left bottom corner of your organization page.

  • Disallow external users joining your organization. In order to protect your projects, pipelines and source code you should disable external user access. This setting combined with an Azure directory integration, should allow only verified users of your company.
  • Disable public projects. Sometimes a project may be created public by mistake and expose a threat for your source code. With the below setting you can disable public projects creation.
  • Enable Log Audit Events. For security purposes you should log Pipeline and user actions. Going into security policies you can enable log Audit events. Then a new pane will be created named Auditing. Through auditing you will have a view on what is happening in your projects.
  • Don’t add users on the Project Collection Administrators group on your organization. This group will provide global admin permissions for your organization and allow changing settings on it. Make sure you have you have only the necessary personnel on this group.

Disable Allow team and project administrators to invite new users. You can disable project administrators from inviting new users. This should prohibit unnecessary invitations on your projects as only Organization administrator will be able to invite new users.

  • Install only trusted extensions inside your organization. Extensions can help you implement more complex functionality on your projects using tasks that have been created from community/companies. However one should be careful for the installed extensions and only allow verified publishers that their code will not harm your organization.
  • Enforce a maximum allowed lifespan for new PAT tokens and also restrict full scoped PAT. When your organization is connected with your company AD you can restrict the full scoped PAT. As full access for a PAT can interact with many aspects of the organization it would be a best practice only to enable the service that is needed. Also a maximum lifespan of the tokens can be enforced so that compromised tokens will expire.

Although every practice you follow cannot protect you 100% the above settings are a good starting point for every Azure DevOps administrator.

Posted on by — Leave a comment

Dynamically checkout github repository based on parameter

In some cases, the DevOps team may need to checkout multiple github repositories in the current working directory of the pipeline. By default the pipeline will download the code of the repository where it belongs.

The below pipeline will download a github repository based on a parameter that user provides. In order to accomplish that you will need a service connection with your github account/organization.

Then using the below pipeline you can download a repository with a specific branch by providing the repository name.

trigger:
- main

pool:
  vmImage: ubuntu-latest

parameters:
- name: repoparam
  type: string
  default: reponame
- name: branchparam
  type: string
  default: main

variables:
  - name: repositoryvar
    value: ${{parameters.repoparam}}
  - name: branchvar
    value: ${{parameters.branchparam}}


resources:
  repositories:
    - repository: gitrepo
      type: github
      name: geralexgr/$(repositoryvar)
      ref: $(branchvar)
      endpoint: geralexgr

steps:
- checkout: gitrepo
  displayName: download repository

For example given that I have created a repository geralexgr/terraform-az-lin-win I will provide only the name of it terraform-az-lin-win and the main branch.

When running the pipeline the selected repository will be downloaded into C:agent/work/buildID/s or /home/vsts/work/buildID/s

Posted on by — Leave a comment

Azure DevOps agent cannot checkout GitHub repository

Recently I faced an issue with my Azure DevOps self hosted container agents. They could not checkout the git repositories and the build stopped due to the default timeout of 60 minutes per run.

This happened for multiple builds, as a result I had to investigate the reason behind this error.

By checking the logs inside the container on the C:\agent\_diag folder I could recognize an error message like the below:

A session for this agent already exists.
Agent connect error: The task agent xxx already has an active session for owner xxx.. Retrying until reconnected.

By searching online, I figured out that this is a reported bug on previous agents versions. In order to resolve, I updated and reconfigured the agent. You can update the agent, either from the GUI or by creating a new container and installing the latest version of azure devops agent.

In order to reconfigure the agent I first took an interactive shell on it.

docker exec -it agent-name powershell.exe

Then inside C:\agent run the below commands.

Reconfigure the agent

This is a temporary fix for your agent. If the problem persists you should open a support ticket on Microsoft to troubleshoot the issue.

Posted on by — Leave a comment

Maintenance Jobs for build agents explained – Azure DevOps

When you need to scale up your infrastructure, you should enable as much automated options for maintenance as possible. One of the available options for devops agents are included under Organization Settings -> Agent pools -> Settings.

There you can define automated procedures for cleanup on your agent pools.

In my setup, I changed the days to keep unused working directories to 20.

The working directories of the agent are some folders with specific numbers inside C:\agent\work.

Every time a new build is initiated a new folder for this specific run is created. If the same pipeline runs more than one time, then the same working directory will be kept and the files will get overridden. For example lets say my pipeline A is bind to the folder 5. Then every time the pipeline A runs, then the folder 5 will be used for the sources (git repositories) builds, artifacts etc. All previous data hosted there will be deleted and written again.

The maintenance jobs will remove any directories than are not used for x period of days. In my example I had set up 20 days for that task.

You can configure agent pools to periodically clean up stale working directories and repositories. This should reduce the potential for the agents to run out of disk space. Maintenance jobs are configured at the project collection or organization level in agent pool settings.

You can check your history under Organization Settings -> Agent pools -> Maintenance History.

You can also download the log and figure out how much data have been deleted.

Maintenance jobs:

Create and manage agent pools – Azure Pipelines | Microsoft Docs

Video tutorial on YouTube: