What is the best way to authenticate for a push to azure devops package feed? - azure-devops

I have an azure devops package feed which was working fine for my purposes, until recently a hard drive failure disrupted operations. Suddenly I found myself unable to push any packages without running into a 401 response. I was able to get it to work eventually after modifying a nuget.config file as described in the answer to this question, but given that this entire process was fairly convoluted, it seems like there should be a much more straight-forward way to set this up when needed. So that in the case I ever need to do this again in the future, and so that I don't have to rely on getting lucky with stack overflow answers, what is the best, most straight-forward method for setting up publishing to azure devops package feeds?

nuget.config is the most commonly used authentication method for push packages to feed. There are two ways to push packages to feed, I think you may need another.
Pipeline push should be a easy way to achieve your requirement.
trigger:
- none
pool:
vmImage: 'windows-latest'
steps:
- checkout: self
persistCredentials: true #This step will do the auth.
- task: DotNetCoreCLI#2
inputs:
command: 'build'
projects: '**/*.csproj'
arguments: '--configuration Debug'
- task: DotNetCoreCLI#2
inputs:
command: 'pack'
packagesToPack: '**/*.csproj'
versioningScheme: 'byPrereleaseNumber'
majorVersion: '1'
minorVersion: '0'
patchVersion: '2'
- task: NuGetCommand#2
inputs:
command: 'push'
packagesToPush: '$(Build.ArtifactStagingDirectory)/**/*.nupkg;!$(Build.ArtifactStagingDirectory)/**/*.symbols.nupkg'
nuGetFeedType: 'internal'
publishVstsFeed: 'xxx/xxx'
You just need to 'click' the feed you want push to and then change the step of YAML like the above.
After that, give the permission to pipeline:
Finally, run the pipeline to push artifact to feed:
Each step of this method is very clearly and each time you want to push artifact, you just need to change several settings is ok(Version, Repo that the pipeline based on, artifact name). Create once, use for a long time.
Additional:
How to change the repo that the pipeline based on:
Repository Structure on my side:
Everything of push artifacts:
Publish Nuget packages(NuGet.exe)
Publish Nuget packages(dotnet)
Publish NuGet packages with Azure Pipelines (YAML/Classic)

Related

Artifact feed for entire organization?

I have many related projects in my organization. When I create an artifact (nuget package) for any project I want to publish that package to a single organization-level feed.
I also want all my projects to consume packages from this feed.
Is this possible?
I currently reference feeds from projects I need to reference as shown in the YAML below - which does not work. With respect to the first question I asked above, what is the correct way to reference packages I need to consume from my local feeds?
task: NuGetCommand#2
inputs:
command: 'push'
feedsToUse: 'select'
vstsFeed: 'Domain.Project/OtherProject#Local'
publishVstsFeed: 'Domain.Project/OtherProject#Local'
First we can create an organization-scoped feed in Artifacts:
Then specify your local package path and target feed location in nuget push task, for example:
- task: NuGetCommand#2
inputs:
command: 'push'
packagesToPush: '..\xx\NuGetPackage\xx.0.0.nupkg'
nuGetFeedType: 'internal'
publishVstsFeed: 'xxxx'
Run the pipeline with the self-hosted agent to push the local package to the organization scope feed of azure artifact.
Default pool: Use it to register self-hosted agents that you've set up.
pool:
name: Default

Cypress Integration with DevOps

What I want to achieve:
I have a repository on Azure DevOps which hosts my web application. I wrote a test suite for UI Automation using Cypress. I created a separate repository for my test cases to check if they are working properly or not. I created a pipeline which has the following content:
trigger:
- manual-tests
pool:
vmImage: 'ubuntu-latest'
steps:
- task: NodeTool#0
inputs:
versionSpec: '10.x'
displayName: 'Install Node.js'
- script: |
npm install
displayName: 'npm install'
- task: Npm#1
inputs:
command: 'custom'
customCommand: 'run test'
continueOnError: true
- task: PublishTestResults#2
inputs:
testResultsFormat: 'JUnit'
testResultsFiles: '**/test-output-*.xml'
testRunTitle: 'My Test Cases'
I have a trigger set to a branch of the repository in which my UI Automation code is stored. What I want is, to trigger my automation script, when there is a push on some branch of the web application repository. Is there a way of doing this? Can we store our test case files in the application repository and give the path of the test script?
It seems that the UI Automation Repo and Web Application Repo are two separate repos.
To trigger my automation script, when there is a push on some branch of the web application repository. Is there a way of doing this?
The function: "trigger a pipeline from a different repo" is not available now.
This feature is still under development. Multi-repository support for YAML pipelines will be available soon for azure devops service.
Please check the function:"Multi-repository support for YAML pipelines" in Azure DevOps Feature Timeline 2020 Q2. This feature will roll out to everyone by the end of July 2020.
Workaround:
You could try to use the Pipeline triggers.
Here are the steps:
Step1: Create a pipeline with web application repository, then you could set the trigger branch.
Step2: Add the Pipeline trigger in the Yaml file (UI Automation Repo).
For example:
resources:
pipelines:
- pipeline: Name
source: Pipeline name
trigger:
branches:
- releases/*
- master
When you make changes in web application repository, the pipeline with the web application will be triggered.
After running the pipeline , the pipeline with UI Automation repo will be triggered.
Can we store our test case files in the application repository and give the path of the test script?
Of cource. You can do it.
If you want to use the test file in the pipeline (UI Automation repo), you could add the repo resouces in the pipeline.
For example:
resources:
repositories:
- repository: MyAzureReposGitRepository
type: git
name: MyProject/WebapplicationRepo
...
steps:
- checkout: MyAzureReposGitRepository
Note: the repo will be check out to the Agent Source Folder.
Hope this helps.

Azure DevOps Linked Work Items in pipeline

How does Azure DevOps identify linked workitems during pipeline (Azure DevOps YAML)?
I believe it is supposed to get only the workitems linked to new commits (i.e. commits which were not included in a previous pipeline)
However, it sometimes seems to link all work items. But this does not always happen. I did not manage to identify the pattern yet. But I noticed that when I do a change in the pipeline YAML, it seems to trigger this behaviour that links all work items again (even if they where linked to a previous commit and not to newly included commits).
Updated to include additional information
This is my build pipeline YAML
name: 03.01.00$(Rev:.r)
pool:
name: Hosted VS2017
demands:
- msbuild
- visualstudio
- vstest
steps:
- checkout: self
clean: true
persistCredentials: true
- task: NuGetCommand#2
displayName: 'NuGet restore'
inputs:
restoreSolution: MySol/MySol.sln
- task: VSBuild#1
displayName: MySol/MySol.sln
inputs:
solution: MySol/MySol.sln
vsVersion: 15.0
- task: WorkItemUpdater#2
inputs:
workitemsSource: 'Build'
workItemType: 'Task,Bug'
updateAssignedTo: 'Never'
updateFields: 'Microsoft.VSTS.Build.IntegrationBuild,v$(Build.BuildNumber)'
- task: VSTest#2
displayName: 'VsTest - testAssemblies'
Pipeline settings:
Processing od new run requests: Enabled
Automatically link work items included in this run: checked & dev branch selected
Triggers:
Override the YAML continuous integration trigger from here: checked
Enable continuous integration: checked
Batch changes while a build is in progress: unchecked
Branch filters
Included dev branch + another feature branch
Path filters
None

How do I configure a build on VSTS to FTP deploy

I want to use VSTS to build and deploy my app (to FTP) when Update the master branch of my project. I have the script below. It works in that it triggers and builds but then fails to deploy because it can't find the files and I don't know what values to enter. I get the error below.
When VSTS builds, where does it put the build files?
I've watched youtube but all the examples are old and don't reflect how VSTS works right now so I'm totally stuck. There are no articles here that reflect how VSTS works right now and the Microsoft pages are no help either.
I'm running out of articles to review and am now pretty much guessing, so any help would be very much appreciated.
# ASP.NET Core
# Build and test ASP.NET Core projects targeting .NET Core.
# Add steps that run tests, create a NuGet package, deploy, and more:
# https://learn.microsoft.com/azure/devops/pipelines/languages/dotnet-core
trigger:
- master
pool:
vmImage: 'ubuntu-latest'
variables:
buildConfiguration: 'Release'
steps:
- script: dotnet build --configuration $(buildConfiguration)
displayName: 'dotnet build $(buildConfiguration)'
- task: FtpUpload#2
inputs:
credentialsOption: 'inputs'
serverUrl: 'ftp://xxxxxxx.xxxxxxxx.xxxxx/'
username: 'xxxxxxxxx'
password: 'xxxxxxxxxx'
rootDirectory: '/'
filePatterns: '**'
remoteDirectory: '/'
clean: false
cleanContents: true
preservePaths: false
trustSSL: false
I changed to this
rootDirectory: $(Agent.BuildDirectory)
and tried this
rootDirectory: $(Build.StagingDirectory)
And now the build succeeds but now I get this error/warning. Nothing is deployed.
When you set system.debug=true, then open the log for detailed compile process, you could see:
It is looking for directory '/' which you specified in the task. But, unfortunately, the content obtained with / is not any part of your repos. Then the server tell you sorry, can not find such file or directory in your repos.
This parameter is getting files or folders from your VSTS repos, so here you need use some words to let server know what you want to take from Repos.
(1) Since this task is in your build pipeline, you could use $(Build.SourcesDirectory) to represent for your whole repos.
(2) Also, if you just want to copy part of repos, such as folder or file, just input them with relative path. For example:
Upload the file upload.json which under the folder jobs, just
input rootDirectory: jobs/upload.json.
Upload one folder or file which in the root path of Repos, just input
rootDirectory: {folder name}, or rootDirectory: {folder name}. Like: rootDirectory: jobs, or rootDirectory: web.config

Skeleton for a CI/CD pipeline as YAML definition

I'm trying to to create a yaml definition file for a simple CI/CD pipeline in Azure DevOps.
My pipeline should look like this:
Is it possible to define the whole workflow in one definition file with different stages and jobs?
How can I determine which project (which GIT sub-path has triggered the build) has changed to proceed with project A/B workflow?
The first workflow with project A seems feasible for me. I can run the sc command together with runsas or psexec to start/stop the service and use a copy file task. But how can I initiate to publish the ASP.NET web application to a local directory (as I would do with VS->Publish->Local Folder)?
After that I guess it's the easiest way to make use of scripts to replace content, install npm packages to minify and bundle js/css files and upload these to a ftp server. Or any better/easier ideas?
If you guys can support me by creating an initial yaml definition just for the workflow without the details of the tasks I would really appreciate that. Maybe I get a more clear vision if you can answer my questions above.
At the moment I have a very simple initial build file:
# ASP.NET
# Build and test ASP.NET projects.
# Add steps that publish symbols, save build artifacts, deploy, and more:
# https://learn.microsoft.com/azure/devops/pipelines/apps/aspnet/build-aspnet-4
trigger:
- master # for a productive deployment after manual approval
- develop # for a automatic test deployment
pool:
vmImage: 'windows-latest'
variables:
solution: '**/*.sln'
buildPlatform: 'Any CPU'
buildConfiguration: 'Release'
steps:
- task: NuGetToolInstaller#0
- task: NuGetCommand#2
inputs:
restoreSolution: '$(solution)'
feedsToUse: 'select'
vstsFeed: 'tpcemedia'
- task: VSBuild#1
inputs:
solution: '$(solution)'
msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactStagingDirectory)"'
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
No, releases are not yet possible in yaml. You can have build stages\jobs, but it makes no sense to use them in such a simple case
Yaml has a path-trigger filter, just configure a build per application. no need to complicate the build with conditions. do something like this:
build1:
trigger:
paths:
include: src/proj1/*
build2:
trigger:
paths:
include: src/proj2/*
Better to separate release and build, this way your release agent will be directly on the server and would be able to restart service locally without the need to have network access (and its more secure). It would also pull the artifacts generated by the build agent "for free".
Why use ftp, just use "publish artifacts" step(s), much easier.