The Issue Whilst working on an Azure DevOps YAML pipeline for a solution that used Git Submodules we hit a problem with the checkout of the repo and submodule using the YAML jobs: - job: 'Build' steps: - checkout: self submodules: true It got the main Git repo, but failed with the following error git submodule sync git --config-env=http.https://myorg@dev.azure.com.extraheader=env_var_http.https://myorg@dev.azure.com.extraheader submodule update --init --force Submodule 'Library' (https://myorg@dev.azure.com/myorg/myproject/_git/Library) registered for path 'Library' Cloning into 'D:/a/1/s/Library'....

The Issue I recently upgraded a clients Azure DevOps server from 2019 to 2022. This required a new application tier VM due to the change in supported versions of Windows Server between the two versions. Unfortunately, the client’s developers had always accessed the old Azure DevOps Server using the VMs FQDN, as opposed to a DNS managed alias. Hence, given they wanted to minimise change, the plan was to create a DNS Alias so they could continue to use the same URLs and TFVC workspaces mappings....

The Issue Last week I noticed that the staging URL that is normally output as a comment was missing from new GitHub PRs. Previously, this URL was added automatically by the Azure/static-web-apps-deploy GitHub Action for PRs in our Hugo based websites. After a bit of digging, I noticed a warning message in the logs of the Action that said: … Done Zipping App Artifacts Uploading build artifacts. Finished Upload. Polling on deployment....

Just a little reminder, probably to my future self, to not call your Azure DevOps YAML Deployment stage ‘deployment’. If you forget you can expect to waste plenty of time, like we did last week, with environment agents not picking up queued jobs with no diagnostic logging messages to give you a clue as to what is going on. This issue has been reported on StackOverflow where it was pointed out that the official documentation used ‘deployment’ as the stage name....

Background I just upgraded our Azure/Docker container hosted SonarQube instance from 10.5.1 to 10.6.0. This was partly due to our usual upgrade process, we try to upgrade within a week or so of a new release, but also to address a specific Java issue we started to see when using the SonarQube@6 Azure DevOps tasks. The error was the SonarQube analysis completed successfully, but the clean up process failed with this JVM error....