From the MS docs:
https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/build/maven?view=azure-devops
mavenFeedAuthenticate Authenticate built-in Maven feeds (Required)
Automatically authenticate Maven feeds from Azure Artifacts. If
built-in Maven feeds are not in use, deselect this option for faster
builds. Default value: false Argument aliases: mavenAuthenticateFeed
But everytime I want to use a Maven feeds from Azure Artifacts and I try this by setting mavenFeedAuthenticate to true I always get 401 (Unauthorized).
Could someone please show me the correct usage of this value?
Please refer to this doc to check if you have given Contributor/Owner role to identities: Project Collection Build Service ({OrgName}) and {Project Name} Build Service ({Org Name}) as this doc described.
In addition, this mavenFeedAuthenticate argument in the Maven task is set to false by default, which means that Azure Pipelines will automatically authenticate Maven feeds from Azure Artifacts in the backend. But if it is set to true, we need to specify PAT with full scopes in settings.xml and add file path pointing to this settings.xml for authentication in Options menu in this Maven task.
Related
How can I change the appsettings on the preview environemnts that are generated by the Azure Static Web Apps CI/CD Github Action for each pull request?
I can go to the portal, navigate to the generated environment and change its appsettings. Doing this manually for each new pull request is error prone and will become tedious really fast.
I couldn't find any reference to this in the Build Configuration For Azure Static Webapps docs so I'm assuming it can't be configured that way.
I also couldn't find any reference to SWA environments in the CLI docs.
I looked into deployment environments but it looks like this is some other kind of deployment environment as it keeps mentioning devcenter.
In Azure Portal, While Creating Static Web App, after providing the GitHub Repo and Branch details, we will get an option to preview the Workflow file.
I can go to the portal, navigate to the generated environment and change its appsettings
Yes, In Configuration Section we have an option to add the App settings. But it is a manual work, which is not advised to follow.
Once we click on Review + create and create the Static Web App, a new folder with name .github/workflows will be created in the GitHub Repository.
It contains the same workflow file (preview file), which we saw while creating the Static WebApp in Azure Portal.
We can edit the Workflow manually.
To update the appsettings/configurations in the workflow, we can specify the steps in the existing workflow file.
We can use either Powershell/Azure CLI commands to update the Appsettings.
az staticwebapp appsettings set --name YourStaticWebAppname --setting-names "message=HelloEveryOne"
***Sample code for Updating App settings: ***
Before Build and deploystep in Workflow, add the below steps.
- name: Build And Deploy
- run : Your Update appsettings Script
To edit the Workflow file, click on the .github/workflow => .yml file
References taken from MSDoc 1 and 2.
Update
As per the discussion in GitHub, adding appsettings to the preview environment is not currently supported in the default Azure Static Web Apps CI/CD.
Setting appsettings on a specific environment is not currently supported in the Azure Static Web apps CI/CD nor by the Azure CLI.
There is a discussion in GitHub about it.
I'm using the github rest api to create repo environments:
https://docs.github.com/en/rest/reference/repos#create-or-update-an-environment
The api allows us to select deployment_branch_policy.custom_branch_policies: (boolean) but I can't find a way of creating a deployment branch rule with a custom pattern, like you would do on the UI:
Is there any way of creating this through the REST api?
Many thanks
It should be possible to do via the Deployment branch policies API:
The Deployment branch policies API allows you to specify custom name patterns that branches must match in order to deploy to an environment. The deployment_branch_policy.custom_branch_policies property for the environment must be set to true to use these endpoints. To update the deployment_branch_policy for an environment, see "Create or update an environment."
For more information about restricting environment deployments to certain branches, see "Using environments for deployment."
We have created a package in our company's Azure DevOps organization; it is uploaded as an artifact and can be used in pipelines in the same organization. This all works perfectly.
We now want to use the same package in a narrow, clearly defined set of other organizations. But when we try to access the package from within a pipeline of another organization, we receive an error message: The package is not found.
How can we give other "organizations" in Azure DevOps access to the package?
How can we give other "organizations" in Azure DevOps access to the package?
You can use service connections to do that. The service connection type you need to choose depends on the type of your package.
Here is an example of getting access to a universal package from another organization.
Step1:
Go to Project Settings -> Pipelines/Service connections -> New service connection -> Azure Repos/Team Foundation Server -> Next.
Connect this project to the organization of the package.
Step2:
If you are using Classic UI pipeline, add a built-in task 'Universal packages'. Choose 'Another organization/collection' in 'Feed location'. Choose the connection you created in step1 and fill in information of the feed.
If you are using YAML, add the following task:
- task: UniversalPackages#0
displayName: 'Universal download'
inputs:
feedsToUse: external
externalFeedCredentials: {service connection}
# if you are using project-scoped feed, replace {feed} with {project/feed}
feedDownloadExternal: {feed}
packageDownloadExternal: {package}
versionDownloadExternal: {version number}
If you want to connect to a Npm/Nuget/Maven/... package, you need to create a correspondant service connection and use Feed URL instead of organization URL. Then in pipeline, you need to run an authenticate task (you can find it in built-in task list) before using the package. Click this document for detailed information.
This is a question on how to use a static value for VSTest unit tests run on Azure DevOps Pipeline.
When I develop a unit test that depends on my Web API, I put URL of the Web API hosted on my local dev machine in appsettings.json and this works great. However, when the unit test is run on Azure pipeline, of course it cannot access the Web API hosted on my machine and it fails. I can change the appsettings.json file to point to Web API on Azure but I wish there is a way to always point to the WebAPI on Azure when the unit test is run on the pipeline, overriding the setting in appsettings.json. Is there such a way?
For the Azure pipeline Release, I know I can set variables for app services with Azure App Service Settings task (https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/deploy/azure-app-service-settings?view=azure-devops). Not sure similar functionality is available for VSTests.
You can use File Transform task to substitute the variables in appsettings.json file with pipeline variables. See here for more information
So you can add a File Transform task before the build task. Then define a variable(eg. TestData.Url) in your pipeline variables.
See below yaml example.
- task: FileTransform#1
displayName: 'File Transform: '
inputs:
folderPath: '$(system.defaultworkingdirectory)'
enableXmlTransform: false
fileType: json
targetFiles: '**/appsettings.json'
There are other tasks can do the same work. You can check out task Set Json Property, and task Magic Chunks
You can also put the URL of the Web API in the TestRunParameters section of runsettings file or Properties section of testsettings file. And modify your test code to get the URL from testsettings/runsettings files. Then you can use overrideTestrunParameters attribute of Vstest Task to override the URL. See Vstest task document for more information.
You need to have two appsettings files. One for dev (you local test) and the other for production (AzureDevops pipeline).
Like this if you need to make some changes to test locally you change only the dev one.
I see several examples of Azure Resource Manager templates, referencing artifacts directly in Git Hub.
As in the following example, taken from this quick start template:
"modulesUrl": {
"type": "string",
"defaultValue": "https://github.com/Azure/azure-quickstart-templates/raw/master/dsc-extension-azure-automation-pullserver/UpdateLCMforAAPull.zip",
"metadata": {
"description": "URL for the DSC configuration package. NOTE: Can be a Github url(raw) to the zip file (this is the default value)"
}
As an orgnaisation, we can't use free Git Hub as code is public and as we pay for VSTS already... At the moment, we have to upload artifacts to Azure Storage Accounts using the VSTS build task Azure Resource Group Deployment task and reference them from there. It would be nice if we could remove this step.
So, is there a way to reference artifacts directly from a VSTS repository in a similar way to Git Hub? I assume the URI would require some form of authentication, such as a PAT token.
All I can find is this, but I think it is referring to packages. I don't need to create packages for ARM templates and DSC configurations.
There is a task called Azure Resource Group Deployment Task, we use this to deploy the ARM template.
According to you sample template, it's using publicly accessible http/https URLs in GitHub. Afraid this is not accessible via vsts url. In VSTS you need to follow below process (Need to use a SAS Token):
You could provide some extra parameters using the output variables defined in the Azure File Copy Task (storageURI, storageToken). This are needed because in the template we use the _artifactsLocation and _artifactsLocationSasToken parameters to build the storage URL to the files.
More details please refer this blog: Setting up VSTS with ARM Templates