First, I'd highly recommend not doing this - a better approach would be to have a single source of truth (that is your repo). Force developers to commit & push changes and let the pipeline do the rest. If it's not in repo, it didn't happen.
If you absolutely have to, then I'd go with "brute-force" way - have a pipeline that triggers ...
I was able to contact DevOps Support and get an answer. The issue was that I could only create Portfolio Backlogs, not Requirement Backlogs. By changing the default Requirement Backlog to include my custom work item, those showed in the Sprints section.
Environment approvals work per-stage. Split your jobs into separate stages:
- stage: development
condition: contains(variables['Build.SourceBranch'], 'refs/heads/develop')
- deployment: Deploy_Dev
displayName: 'Deploy Develop to Dev Machine'
I'm not familiar with Invoke-Build, but appearantly it's a part of the InvokeBuild PowerShell module? In that case, you'll have to install the module as part of the script where you're using it. Your YAML should be something like this:
- stage: Build
- job: Build
- task: PowerShell@2
If your after the branch name, and your branches don't include "directories" (example: releases/my_release), then Build.SourceBranchName will you give you "The last path segment in the ref". So, if Build.SourceBranch is refs/heads/master, then Build.SourceBranch will be master.
The issue is that you can't reference the changed value in the same task.
I created a new Powershell task and just called Write-Host "env:IP environment variable set to ($env:IP)" which output the IP address correctly.
Pipeline Variables are handed to PowerShell as environment variables, which means that $ip exists only with the script while you want to use $env:ip to pick the environment variable value.
Note Secret variables are not passed automatically: you must add an explicit env: in YAML or as arguments in Classic Editor. The latter means that the PowerShell code must ...
AFAIK currently there is no way to label job so that it is easily identifiable from the Overview screen. If interested, you may raise feature request in this UserVoice / feedback forum. I see this related feature request already raised so you may even upvote it. In general, Azure feature team would check feasibility of a feature request, triage it, ...
This was answered via StackOverflow by Kevin Lu:
In short, the second suggestion he made to update to PowerShell 7 and adding the environment information worked. I also had to run the script to reregister the Azure agent on the target server.