UPDATE: I think this question was based on a fundamental misunderstanding. When creating the build pipeline definition, I would pick the saved service connection ("GitHub-iQmetrixService" in the screenshot), and then later Azure DevOps would continue to prompt for access to my personal account. This made me think that the build pipeline was linked to my personal account somehow, such that if my account is ever in the future gone or otherwise unable to access the repository, the build pipeline would stop working.
As far as I now understand, this is not the case. The build pipeline definition itself is in fact associated with the service connection, and the reason that Azure DevOps prompts for my personal login is because the integrated YAML editor is going to want to make commits back to the repo, and those commits need to happen "as me". When co-workers go to the pipeline editor, they too are prompted for their personal login.
I'm still a little bit nervous about this understanding, because I can't see anything in the UI that shows what service connection Azure DevOps is using primarily to process the build pipeline, nor can I see any way to change it should that ever be necessary.
When creating a new Build Pipeline, if I tell Azure DevOps that my repository is in GitHub, I am immediately redirected to GitHub to authorize access to my personal GitHub account (to which I have an ambient login). If I instead pick "Other Git", then the next step in the flow lets me say that the source is GitHub, at which point the screen says:
This authorization, set up by someone else in my organization, works just fine, and I can view all of the organization's repositories and set up a new pipeline. But then, if I close the window and try to re-open the pipeline editor, I am immediately redirected once again to the GitHub page to authorize access to my personal account. Editing the pipeline created based on the "GitHub-iQmetrixService" connection does not use the connection and instead wants to establish a new connection based on whatever individual accounts I have access to.
How can I edit the pipeline without creating a connection to the repository that is linked to my own personal account?
As work around, you can take advantage of the browser sessions and cookies.
Configure the browser to let it retain and keep the session. And do not clear the session and cookie data once you close the browser.
For me, I am using Edge. So, I go Settings -> Privacy and Security -> Choose what to clear, then disable the option
After configure this, I do not need input my account, password and Verification code again while I close the windows, re-open and re-edit the pipeline,
If you want to make some configuration changes on this pipeline, please go right corner-> three dots, and choose the Triggers.
After located to the Triggers page, please change to YAML tab.
Then you can do the modified on this pipeline
To provide some clarity, it appears what's going on here is that for YAML build definitions, Azure DevOps doesn't actually go to the build pipeline definition editor when you select "Edit". The YAML text editor it takes you to is in place of the build pipeline definition editor. But, the definition editor can still be reached. #Merlin Liang - MSFT's answer provides (after the horizontal rule) the steps to take to do this. I didn't understand why those steps, though. I created the following graphic to explain specifically the aspect that wasn't clear in my head:
Related
I'm trying to solve this flow:
Developer opens a PR.
Build validation finds some static code rules are being broken.
Developer has the option to ask for a manual review, this is some kind of action that can be performed from the PR (a button click, link, etc.) that will automatically open a DevOps work item.
I can solve the opening of an automatic WI, but is there any way to add a custom button on PRs? Maybe using extensions?
I saw the service hooks, but these are triggered automatically, I need something that will be triggered manually directly from the PR.
Thanks!
I have confluence page, where I want to store all my feature files(specflow), so that Business can have a look. Currently these feature file resides in a repository in Azure Devops. Is there a way to dynamically link these two , so that Confluence gets updated with the latest feature files ?
Thanks,
Rajee
I have the same basic problem, too. Our code is in DevOps and our product owner needs access to the feature files, but without a higher license in DevOps they cannot see repos.
I submit a pull request even to include new features. I mention the work item Id for the epic, story, feature or bug it pertains to in the commit message. I like to use conventional commits for commit messages in this case:
docs: Cucumber tests for X feature (related #1234)
(where #1234 is the work item Id in DevOps)
Make sure the epic, feature or story is linked to the pull request in DevOps.
Upon completing the pull request DevOps adds a link from the epic, feature story or bug to the pull request, providing some traceability to the real code.
Next, I copy and paste the feature files and scenarios into the acceptance criteria for stories, steps to reproduce for bugs or the description for features and epics. I also include a relative file path in the work item description to the feature file:
(copied and pasted from Project.Specs/Foo/Bar.feature)
Feature: ...
In order to ...
As a ...
I want to ...
Scenario: ...
Scenario: ...
It's a manual process, but you could adopt something similar in Confluence. You might not get the link from the commit to the wiki document, but basically copy and paste is your only free choice.
If your customers have read access to DevOps (which they should) adopting the procedure I outlined above at least gives you some traceability between the work item and a pull request that added the features to the repository. Then it is a manual step to copy and paste the features into the work item descriptions or acceptance criteria so the customers can review and approve. Annoying? Yes. But it does the trick.
When I get a code review from another person, sometimes the code review states the project name and list the files that are contained in the review. More often than not, it just says none. (please see red box in the image below)
Unless the person gives a good title, it can be difficult to know which project I need to review.
When I open the review, all of the files show up and everything works just fine.
Its only the email that seems to be the issue.
Does anyone know how to resolve this?
I can reproduce above issue. It seems that the problem resides in azure devops server.
You can report this problem to microsoft development team. Hope they will look into this issue and provide a fix soon.
Click here to report a problem(Click Report a problem and choose Azure devops or Azure devops server if you are using on-premise server).
Is there a standard url that always shows the latest running build of a particular pipeline?
In this one build Id is needed.
https://dev.azure.com/myOrg/MyPrj/_build/results?buildId=**1029**&view=results
So Always I am forced to go builds list and pick the one on top. Two clicking and two page loads. Would be nice if I can always reach here on one click.
The answer is Yes.
You can go the latest running build of a particular pipeline by clicking below url:
https://dev.azure.com/{org}/{proj}/_build/latest?definitionId={definitionId}
The DefinitionID is id of the pipeline. Yon can get it on the address bar when you click the pipeline.
Update:
Above url is not documented. I just tested it on my pipeline and found it was working.
If it was working in your case, You can click this url https://dev.azure.com/{org}/{proj}/_build?definitionId={definitionId} to go to the pipeline history page. But you will have to manual pick the one on top in this way.
You can also submit a use voice for this standard url to microsoft development team. Hope they add this to azure devops pipeline.
I'm currently using AppCenter to Test my Xamarin app. The complete suite is being run at night. But I'm currently looking for a way to make this part of my CI builds to introduce an extra quality gate before features get merged.
However, we would need to slim down the amount of tests that need to be run otherwise this would become unmanageable. For this we can specify categories on our App Center test build step. When queued manually I'm able to specify the categories, however when we make this CI Build part of a branch policy and use a manual trigger for our build validation we are unable to specify the categories as we don't get the popup when queuing.
Any suggestions on how to adres this issue differently?
Seems you want to set build variables in pull requests when you queue the build under policies.
Unfortunately, this could not be achieved by now. It will not pop up the dialog when you queue the build. There has been a related uservoice, you could vote up and follow it, TFS PM will kindly review your suggestion.
Allow Setting Build Variables in Pull Requests
https://developercommunity.visualstudio.com/idea/365725/allow-setting-build-variables-in-pull-requests.html
The only workaround for now is editing the build definitions and add the variable under variables directly, then queue again. You could clone the original build definition first.