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
Related
I am using Azure DevOps UniversalPackages#0 task to download from an Azure Artifacts feed. I am using this link to set the values of UniversalPackages#0 task. By looking into my Azure DevOps project artifactory, no where can I find the two arguments vstsFeed and vstsFeedPackage. These values are mandatory for the task:
- task: UniversalPackages#0
displayName: 'Download Artifact with Universal Packages'
inputs:
vstsFeed: '****'
vstsFeedPackage: '****'
vstsPackageVersion: 0.8.4
Please note that I know by using classic editor and using universal packages task I can generate the yaml file. But that's not what I want. I want to know how via DevOps API or from the DevOps portal I can find these two values and put them in the above code.
Here is what I see when I check my feed in Azure Artifacts. As you see no where these values (vstsFeed and vstsFeedPackage) are mentioned.
Instead it is something like: vstsFeed: '00000000-0000-0000-0000-000000000000/00000000-0000-0000-0000-000000000001'
This vstsFeed is composed of projectid and feed id. For example: vstsFeed: Projectid/Feedid
To get the Vsts feed id and the package id, you can use Rest API: Artifact Details - Get Packages
GET https://feeds.dev.azure.com/{organization}/{project}/_apis/packaging/Feeds/{feedId}/packages?api-version=7.0
In the Response, you can get the project id , feedid and package id.
The task also supports defining feed name and package name.
For example:
- task: UniversalPackages#0
displayName: 'Download Artifact with Universal Packages'
inputs:
vstsFeed: 'projectname/feedname'
vstsFeedPackage: 'package'
vstsPackageVersion: 0.8.4
You have to return one level to Artifacts view. Then, in the drop down menu, there is Artifact feed name (vstsFeed), and below there are Artifact feed packages (vstsFeedPackage - in your case "py_dataenginee..." without semantic version at the end).
More details in picture
According to the documentation, the values in your screenshot are named differently, but still able to pair them according the documentation:
vstsFeed - Feed
vstsFeedPackage - Package name
source https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/reference/universal-packages-v0?view=azure-pipelines
I've added notes to your screenshot.
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)
Azure static web apps(preview) currently only works with a github account, and as a company policy we have to use Azure for repos and everything else (pipelines, releases, etc..) We are going to use the static web app just for viewing a simple angular website however all the source code must remain in the azure devops repo.
Is is possible to create a private github account and upload to it only the compiled angular files to make use of the static web app? for example we already have a pipeline to compile and deploy the angular website to an Azure web app service, can this pipeline be modified to publish the same files to the github account? and if so how?
You can do it in Azure Devops. Try put this YML in Azure DevOps Pipeline
trigger:
- main
pool:
vmImage: 'ubuntu-latest'
name: 'yourApplicationName'
steps:
- task: NodeTool#0
inputs:
versionSpec: '12.x'
displayName: 'Install Node.js'
- script: |
npm install -g #angular/cli
npm install
displayName: 'npm install'
workingDirectory: '$(Build.SourcesDirectory)/yourApplicationName'
- task: AzureStaticWebApp#0
inputs:
app_location: "/yourApplicationName"
api_location: "api"
app_build_command: $(build_command)
output_location: "dist/yourApplicationName"
env:
azure_static_web_apps_api_token: $(deployment_token)
You can put build_command and deployment_token in the variables
Azure SWA is only available for code in Github at the moment.
However, you can get something pretty close with Azure App Service. Microsoft even has a couple blog posts about how to configure Azure App Service, Azure Repos and Azure Pipelines together.
You can deploy a React Static Web Apps from Azure using Pipelines as follows:
name: Azure Static Web Apps CI/CD
#
# Trigger off of changes in master or another branch(s)
#
trigger:
branches:
include:
- TestBranch
jobs:
- job: build_and_deploy_job
displayName: Build and Deploy Test Web App
condition: or(eq(variables['Build.Reason'], 'Manual'),or(eq(variables['Build.Reason'],'PullRequest'),eq(variables['Build.Reason'], 'IndividualCI')))
pool:
vmImage: ubuntu-latest
variables:
- group: <Name of your Static Web App Resource Group>
steps:
- checkout: self
submodules: true
- task: AzureStaticWebApp#0
inputs:
azure_static_web_apps_api_token: $(AZURE_STATIC_WEB_APPS_TOKEN_#####)
# Details at https://aka.ms/swaworkflowconfig
app_location: "/" # App source code path
api_location: "" # Api source code path - optional
output_location: "build" # Built app content directory - optional
app_build_command: 'chmod 755 scripts/*.sh;./scripts/WebAppBuild.sh prod'
You will first need to set up a connection in Azure->Settings->Pipelines->Service Connections. Use the Pipeline wizard to set up all the initial YML.
The key for me was to run my own build in WebAppBuild.sh which basically runs "npm run build". My repo has a scripts folder. The job/task performed the rest of the install
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.
In Azure DevOps we have created both build and release pipeline using classic way and now we are planning this to convert to yaml file.
But it seems in yaml method, the code can be put only on the root of the repo, where we want to keep the build yaml files in a separate repo, where the developers won't have access.
How can achieve this?
You can use templates, put in the main repo only the minimal yaml that refers to a template with all the steps, the template exits in another repo.
For example, your main repo yaml:
resources:
repositories:
- repository: templates
type: git
name: Contoso/BuildTemplates
jobs:
- template: common.yml#templates # Template reference
In in the repo: Contoso/BuildTemplates put the full yaml:
# Repo: Contoso/BuildTemplates
# File: common.yml
parameters:
vmImage: 'ubuntu 16.04'
jobs:
- job: Build
pool:
vmImage: ${{ parameters.vmImage }}
steps:
- script: npm install
- script: npm test
Restrict the access to the second repo (unless the agent pipeline user).
Read here more info about the resources.
I agree that one solution could be the one proposed by #Shayki Abramczyk
but to have standalone *.yml in dedicated repository you can use 'git clone' while using 'Git Credentials' to access the other repository that contains the files you want to build by the pipeline.
If your repository dedicated for *.yml is in the same Azure Devops project then you should not have any problem with the release definition.
Please see example *.yml that works for us as described:
pool:
vmImage: 'your-preferred-image'
variables:
solution: '$(Agent.BuildDirectory)/**/YourSolution.sln'
buildPlatform: 'Any CPU'
buildConfiguration: 'Debug'
urlWithCreds: 'https://YourUser:YourPassword#dev.azure.com/YourOrganization/YourProject/
_git/YourOtherRepository'
steps:
- task: CmdLine#2
inputs:
script: |
git --version
git clone --quiet $(urlWithCreds)
git checkout master
- task: VSBuild#1
inputs:
solution: '$(solution)'
msbuildArgs: 'your build args'
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
You don't have to keep the YAML files in the root of the repository; ours are in a dedicated sub-folder:
That's crucial, because it means that we can add a PR policy which restricts who can approve changes to any of the pipeline YAML files.