Azure DevOps Release Pipelines permission - azure

I have two projects in my Azure DevOps environment. Project H and Project HB. Project H contains the Board of Tasks and Repo for source code. Project HB contains the build and release pipelines. The build works as it shoud, as does the release pipeline.
But I get an error in the "Release" view, when looking at the Commits made for the release.
TF401019: The Git repository with name or identifier '' does not exist or you do not have permissions for the operation you are attempting.
Which permissions should I configure to get the release to be able to show the commits and Work Items related to the release?
Is it possible to report the deployment status back to boards that exists in another project?
I Tried to add Read permission to the repo and boards in "Project H" for the account "Project HB Build Service".

1
We have the same problem with the Stakeholder access.
Team members can open the page in your screenshot, but stakeholder have the issue as described by you.
So, it's not about the Build Service access, but the user who opens the release status should have access to Project HB.
If the user already has access, then this might be a limitations within the classic release overview.
2
Two answer the second part, you should however see the build status, of the yaml pipeline, in the work items of project H.
The deploy status, of classic release pipelines, is a different story.
AFAIK it's only reported back to the project it is in.
Maybe publishing a deployment badge can help you:
3
Alternatively you could migrate to YAML pipelines, since reporting back of these pipelines have more options then the classic release pipelines.

Related

azure devops | keep history releases from specific branch

I want to keep all the history from our master branch, 1 year
the history deleted after 2 or 3 months and is bad we want to keep our production history....
To keep all the history from the master branch for a year, you can set up branch policies in Azure Devops.
Go to the Branches page in the Repos section of your project.
https://learn.microsoft.com/en-us/azure/devops/repos/git/branch-policies?view=azure-devops&tabs=browser
You could see the doc for details.
If you are using an on-premises Team Foundation Server or Azure DevOps Server, you can specify release retention policy defaults and maximums for a project. If you are using Azure DevOps Services, you can view but not change these settings for your project.
And for every release pipelines, you could see retention policy for each stage but not specific branch. You could go to release pipelines and edit release then you could see 'retention' for the release.
For individual key releases, you can click on (…) of one release pipeline and choose “retain indenfinitely”.
BTW, neither the pipeline's retention policy nor the maximum limits set by the administrator are applied when you mark an individual run or release to be 'retained indefinitely'. It will remain until you stop retaining it indefinitely.

Is it possible to disable manual publishing of Azure Functions?

We have an Azure Function and an Azure DevOps Pipeline, the pipeline builds and published the code of the function's repo automatically. We want to escape discrepancies caused by, potentially, people manually publishing a version of the code, from within their Visual Studio, that is not in source control.
How can we ensure that?
Is there a way to disable manual publishing and only allow the Azure DevOps Pipeline to publish code to the function?
I am referring to a person using the "Publish" option in Visual Studio. Is there a way to forbid the Azure function from accepting such a publish?
To stop manual changes to the build, yaml files and pipeline would be to restric access to the build section of the pipeline for all the users.
This way no one will be able to change the pipeline but the admin user will still have access to the pipeline.
To set the permission we have to go to manage security which is under the pipeline tag.
Then we can select the permission for the users.
Here each tag represents a permission. Since we want to stop manual deployment we would set Edit build pipeline and Edit quality pipeline to deny.
These permissions can be set for individuals as well as security group.
Reference:
permissions in devops.

End to End Traceability in Azure DevOps for any work item until deployment

in azure DevOps, if changes in the form of the work item are committed. That WI further builds and deployed... So can I get a tabular data as when it was build/rebuild and deployed in any of which environment and what is the current status of that WI?
You will be able to get this info as below:
While commiting the code changes you should associate the work item
After commiting the CI Build will trigger. Post that in that work item, there will be link reference to the Build
And when this build is deployed to any of the release environments, it will be displayed under. You can check this new feature introduced in Azure DevOps here
But if you want all this information in a table, in one single view. You have to use Azure DevOps REST APIs to build a customer report to get all the data in one place.

Can we publish artifacts in release pipeline - Azure devOps?

I have a java application and am trying to use Azure DevOps to build and deploy. Am able to do a build and publish the artifact in the build pipeline. In the release pipeline, I stages (dev/train/prod) in each stage I have a maven task to detokenize the build specific to the environment which I am able to do but I want to publish it as a artifact similar to the one in build pipeline. Is there any task to do that or any other alternate approach?
Can we publish artifacts in release pipeline - Azure devOps?
Sorry for any inconvenience.
This behavior is by designed and MS replied they don't have plans to support uploading folder/artifacts from release in near future.
When you check the document Publish Pipeline Artifacts task, It stated that:
Use this task in a pipeline to publish artifacts for the Azure
Pipeline (note that publishing is NOT supported in release
pipelines. It is supported in multi stage pipelines, build
pipelines, and yaml pipelines).
And if you check directly code that is executed, then you can see the Publish Pipeline Artifact task works only for Build pipelines.
You could check this ticket on github for some more details, many communities are waiting for publish artifact from release pipeline.
So, I helped you add a request for this feature on our UserVoice site, which is our main forum for product suggestions:
https://developercommunity.visualstudio.com/idea/823829/support-publish-artifact-from-release-pipeline.html
You could vote and add your comments for this feedback. When there are enough communities vote and add comments for this feedback, the product team member will take this feedback seriously.
Hope this helps.
I was facing the same problem: I wanted to upload artifacts in a release pipeline and in a later agent phase download those artifacts again.
Based on some answers from a related SO Post I created an Extension that offers the possibility to:
Upload a file or a folder to the Release Logs
Automatically download an Artifact from the logs that was previously uploaded
The upload task is making use of the built-in logging command to add files to the Release Logs. The download task then queries the Azure DevOps REST Api to download all logs collected thus far, tries to find the specified artifact and copies it to a specific place.
If anyone is interested, it can be found on the Marketplace

Setup Azure Pipelines from Visual Studio 2017 Community

I am facing an issue with setup of azure pipelines. I am stuck with this window, where it will not give me any option to select azure project.
Here is what I have done already.
created a repo on github.
created an AzureDevOps account and created a project.
Build agent is setup along with build configurations in AzureDevOps which is getting the source from GitHub repo.
How can I get my AzureDevOps project to be populated in the given image?
Somehow I found a crude way to fix this issue, this may not be the ideal solution.
Now I am able to see the azure devops project. It looked as if I have multiple Azure subscriptions mapped to my account and there was a conflict somewhere.
I deleted the %local% folder.
The absolute path is C:\Users*USERNAME*\AppData\Local

Resources