I've recently set up an Azure DevOps Server 2019 on our local servers using TFVC for our source control. Our branch is structured as follows:
root
- App1
- App1a
- App1b
- etc
- App2
- etc
- Utils
Our build scripts, test utilities, apps used during the build, etc are stored in Utils. What I want to do is only perform a build when changes occur anywhere in root except for Utils. I've seen the option to exclude paths in SO but it's only with GIT libraries, is this possible with TFVC?
The solution I'm using to work around this is from Triggering Azure DevOps builds based on changes to sub folders
, but the build still executes, not the actual build mind you, but the pipeline which then triggers a notification to the team that it was successful. Ultimately I don't want it to run at all unless changes have been made outside of Utils. I also don't want to re-organize the folder structure either since a lot of our utilities have relative paths. I've got the trigger setup as
Thanks in advance.
You can exclude the utils folder in the CI trigger options:
Related
For my application I have a solution file (.sln) containing the "main" application assembly (c:\src\app) and the three internal libraries that are used: c:\src\lib\Lib1, c:\src\lib\Lib2, and c:\src\lib\Lib3.
I also have a c:\src\azure-pipelines.yml file that builds (and tests and publishes) my solution file. The pipeline's triggers are branch triggers (e.g. main and patch), with a set of path filters, one for each assembly:
trigger:
branches:
include:
- main
- patch/*
paths:
include:
- app/*
- lib/Lib1/*
- lib/Lib2/*
- lib/Lib3/*
I know that more lib/ projects will be created and added to my .sln over time, and I want changes to those libraries to trigger my pipeline, so I know that I'll need to add to both the .sln and the .yml, and ideally at the same time.
But the solution already lists the project folders, which is exactly the set of paths that I want to trigger on!
How can I take advantage of this? I'd like to do something, maybe during a local (workstation) build, to automate updating the paths/include list based on the solution contents. At the very least getting the .yml to show up in my source control as having changed would be useful.
Anybody know if it is possible to pass in a repo name / base the build on a dynamic repo name? This would allow us to share the same build definition across different branches, cutting down on definitions when creating a feature branch, etc.
When using a TFVC repo we would store the different releases in the same repo but different paths. We could reuse the same build definition across different releases/FB's by altering the source path such as $/product/$(release)/......
It appears Git likes to have the repo hard-coded into the build (hence the dropdown - no way to plug in a variable.
While the question is targeted to On-prem Azure DevOps, if it is possible in the hosted environment it would be helpful to know.
I recommend using YAML build templates. By default these check out "self" and are stored in the repo. That way they work on forks, branches etc. Each branch can contain tweaks to the build process as well.
With the 'old' UI based builds this isn't possible.
What you are looking for is actually two things:
templates - this allows you reuse definition accross different pipelines
triggers - this allows you to trigger pipeline when commit happens on different branches
Looks like Task Groups solved the need (mostly). I was hoping to have one build definition that could be shared across multiple branches; while this appears to be possible on the hosted model, on prem is different.
I am able to clone a build (or use templates) to have an entry point into the repo/branch to get the sources, then pass off the work to a common task group. If I need to modify the build process for multiple branches, just modify the task group.
I've recently been working on switching from On premise TFS to Azure DevOps, and trying to learn more about the different pipelines and I think I may have had my Build pipeline do too much.
Currently I have my Build Pipeline do
Get Source code from Repo
Run database scripts/deploy dacpacs
Copy files over to virtual machines that have web application set up already
Run unit/integration tests
Publish the test results
I repeat these steps closely multiple times, one for develop branch, one for current and previous release branch.
But if I want to take advantage of the Releases and Deployments areas what would that really get me?
It looks like it would be easier to say yes this code did make it out to this dev/beta environment.
I'm working with ColdFusion code that includes some .NET webservices within the repo, would I have to make an artifact that zips up the repo and then deploys it, or is there a better way to take advantage of the release pipeline?
It's not necessary to make an artifact that zips up the repo and then deploys it. There are several types of tools you might use in your application lifecycle process to produce or store artifacts. For example, you might use version control systems such as Git or TFVC to store your artifacts. You can configure Azure Pipelines to deploy artifacts from multiple sources. Check the following link for more details:
https://learn.microsoft.com/en-us/azure/devops/pipelines/release/artifacts?view=azure-devops#sources
I have a Azure DevOps Git Repo with many solutions in it, and are starting down the path of build, test, deploy automation.
I figured out how to run a rebuild if any file changes in the repo.
However, since the repo has many solutions in it, I only want to run a given rebuild of a solution if a specific subfolder changes.
Is that possible, and if so, how do I accomplish this?
you can use path based trigger filters (i'm fairly certain they are only supported in yaml builds). example:
trigger:
paths:
include:
- folder1/*
- folder2/somefile
- etc
Reading:
https://learn.microsoft.com/en-us/azure/devops/pipelines/yaml-schema?view=azure-devops&tabs=schema
https://learn.microsoft.com/en-us/azure/devops/pipelines/create-first-pipeline?view=azure-devops&tabs=tfs-2018-2
We have a release definition which delivers a bunch of asp.net core services along with an Angular app.
Most service are not updated very often so the question is how to compare an artifact version with already deployed into an environment and skip if the latest version had been deployed before?
We have multiple environments in the pipeline.
I dont think it is possible, at least natively, you can calculate file hashes and dont deploy if they match, another option would be using path triggers to filter when an app is build. for example, your directory structure looks like this:
root
|--app1
|--app2
etc
you can define path filters in your yaml build like this:
trigger:
paths:
include:
- app1/*
- sharedlibs/* (if you have them)
this way build will only trigger if there are any changes to files in those directories
You can add additional release environment to check current artifact version through PowerShell (e.g. Build.SourceVersion, check variables in release), then fail task if there was already successfully released.
For Staging environment, choose After environment option and select previous environment.
On the other hand, since you have mentioned most service are not updated very often, you could use 4c74356b41's suggestion to filter build, to only build and release the changes you want.