For security reasons you may want to store the pipelines to another repository than the one that the code is hosted. Lets say for example that you have your application code located on test-project/repository location but your pipelines are stored on the consoleapp1 repository. Also you want to have continuous integration and deployment for the repository on which the code is hosted, so when code is pushed to repository then the pipeline should trigger which is hosted on ConsoleApp1.
You can do that using the repositories resource of azure devops. You will need to define the repository and also configure trigger for this repository based on your strategy.
The final result would be the pipeline to run when code is commited on the code repository instead of the one that pipelines are hosted.
Azure DevOps agent is the tool on which the automation pipelines will run. Microsoft has already created predefined agent pool (macos, ubuntu, linux) for administrators to run their pipelines. These agent pools can be selected using the vmImage instruction.
pool:
vmImage: 'windows-latest' or 'ubuntu-latest' or 'macos-latest'
I have already documented the DevOps agent creation procedure and can be found on the below URL.
During the installation, the agent working directory should be selected. This is the installation path, where the pipelines files will be stored during the execution. Lets say for example that you select the C:\agent directory. During the installation a folder named work will be created and also some other folders as _diag, bin, externals. Inside the _diag folder the logs for the agent are saved.
As a result if you need to troubleshoot an Azure DevOps agent you should investigate the logs under C:\agent\_diag
Inside the work folder the pipeline files that are necessary for the runs are saved. For every pipeline run a new ID is created that will store all the files that are necessary for this run. This will be the run working directory and it is isolated between different runs. The numbers represent a build pipeline run and folders that begin with the letter r represent a release pipeline run.
Inside the pipeline working directory there is also a sub hierarchy with three folders (a, b, s).
The a folder is used for the artifacts and can be used to place output files. The b folder is used for builds The s folder is used for the source code checkout of repositories.
You can access these folders using the predefined variables. For example you can find the a folder with $(Build.ArtifactStagingDirectory) or the sources folder using $(Build.SourcesDirectory).
These predefined variables will let you interact with the building and publishing procedure and you should avoid using static entries like indicating the path itself (best practices)
Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here:
Cookie Policy