I would like to create a Release Pipeline that, after a few tasks, stops and prompts a user to enter a value, then continues.
In the docs I found the exact scenario I was looking for, see the following link
Unfortunately, if I read the suggested links Manual Intervention and Manual Validation, it is not really explained how to reproduce the scenario.
I don't even know where to start, do you have any advice?
Thank you very much for your help.
Related
Our client is asking if there's a way for us to provide them a list of testers who have executed test points in DevOps. I saw that each test point would have execution history. If there's a way to export those details (please see attached screenshot), that would really help.
You can bulk export Test Cases from a Test Suite like the following:
Link: https://www.ecanarys.com/Blogs/ArticleID/415/Bulk-Export-Import-Test-Cases-to-Azure-DevOps-Test-Plans-using-CSV-file
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:
I am currently working on the CI of project and I deploy a preview for each github branch that pass all integration tests.
My CI workflow is executed by CircleCI and I can see the progression on github with Github checks. It works pretty nice but description does not reflect what really happens.
For instance I can see this on github :
My problem is I would like to custom message and details actions link. My last job deploys a preview and I would like to be able to put the link somewhere. The best case should be able to open my preview when I click on details button.
Is there any way to do this ?
I send a mail to CircleCI support and I got this anwser :
Hello,
It is not possible at this time to customize this text. Clicking the
details link will bring you to the job on CircleCI. We are currently
working on a utility that will allow you to post comments to the PR
from within a job that may be close to what you are looking for. This
will exist in an Orb (https://circleci.com/orbs/registry/) but I could
not say exactly how long until this is released, though we are
actively working on it.
You may wish to post to our public facing ideas portal:
https://ideas.circleci.com/ideas as a new idea post. This will let our
community vote for this request. Please let us know if we can assist
any further.
So, unfortunately it is not possible yet. Maybe in the future.
I'm trying to execute a bit different build steps in VSTS based on type how build was started: automatically or manually.
I'm especially interested in accessing that information from powershell script. But so far was not able to find suitable solution or workaround.
Did someone faced similar requirement before? How did you solved it? I would appreciate your help!
Seems you want to know whether the project build is happening through TFS triggered build or manually triggered build.
There is no such feature for vnext build for now. About this , you could submit your uservoice to this link, TFS Product Team is listening to your voice there.
As a workaround either to use two build definitions through different version patterns or manually add a specifical tag after a manually build finished. Through using tags to set some labels on the build to distinguish manual and automatic builds. But this is a manual action, it would be better if we can do this automatically.
It seems to be I've managed to find an option that allows to determine wherever build was triggered automatically or manually.
All builds started manually have actual user in $Env:BUILD_QUEUEDBY variable, while automatic builds have system account there. My value was [********]\Project Collection Service Accounts.
I don't know how reliable it is, but for me so far following code did the job:
# Identifying who triggered the build
$OwnerId = $Env:BUILD_QUEUEDBY;
$OwnerId = $OwnerId.ToUpper();
if ($OwnerId.EndsWith("PROJECT COLLECTION SERVICE ACCOUNTS"))
{
Write-Host "Build was triggered automatically. Resulting files considered 'BETA'"
}
else
{
Write-Host "Build was triggered manually. Resulting files considered 'STABLE'"
}
This trips up a lot of newcomers to TFS, and I'm keen to hear your solutions.
So you've fixed a bug, tested it, looks good, everyone is on top of you to get it out as soon as possible, so you queue a new remote build, wait patiently, then put it into test/production only to find out it's actually an old version - you forgot to check in before doing the build!!
OK, so this is a common oversight, and it costs valuable time. Is it possible to pop up a warning first, or is there some neat trick other have found to avoid this?
Instead of manually kicking off a build after you check-in, what if you set up a "Continuous Integration" build so that the build would be automatically kicked off once you checked in? This way it would be impossible to forget to check in your changes. Here is an article on how you can set that up: http://msdn.microsoft.com/en-us/library/bb668971.aspx.
Continous Integration as mentioned above is the best solution! :)
But you could write a custom activity within your build definition to check if there were any new changesets since the last build and if there is no new changeset show a warning message in the build log or something, but then again the developer has to read to log otherwise it's not useful.
I wouldnt spend any time at all for something like this, I would rather knock on the developers head everytime he misses the check-in! :}