Is it possible to check in VSTS was build stated manually or not? - powershell

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'"
}

Related

VSTS build step changes log trails

In VSTS builds, is there a way I can know who have make changes in build steps?
Can I get history builds?
The reason for this is, we have a big team. Many time it happens that someone changes the build step for some reason and we never know who made the changes and why.
Like in git repo, we know which file is changed by who and why (in comments).
In VSTS builds, is there a way I can know who have make changes in build steps? Can I get history builds?
The answer is yes. You could check the History of the build definition:
Click on the three horizontal dots and we will get an option compare difference, through which we can know the details of the pipeline modification. If the modifier adds a note when saving the modification, we can also know the reason for the build pipeline modification.

VSTS Build variable on Pull Request

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.

How to mention integration service name during importing workflow in a versioned repository from one environment to another

Whenever I try to import a workflow from Dev/Test environment of a versioned repository into Production environment which is also versioned, I get a option where it asks me if I want to Check in or continue without check in. What happens if I do not check in and continue? Will all the objects used in the workflow will not be checked in or is it just the workflow which will not be checked in? I am asking this because, it will be double work if all the objects used will not be checked in including the Workflow, then, I have to go one by one to check in the objects. If I check the check in option for the workflow, after importing the Workflow, the integration service is left blank and when I run it, it is pointing towards the Integration service not mentioned error. For this I generally check out the workflow once I import just to mention the Integration service name. I do not think this is a good practice. Any advices on this will be greatly appreciated.
Thanks
Dhruuv.
Will all the objects used in the workflow will not be checked in or is it just the workflow which will not be checked in?
The objects that will be left in the checked out state are:
the workflow,
the new objects (i.e. they were not present in the Prod repository before the import from Dev/Test),
the modified objects (i.e. they were present in the Prod repository but were overwritten because you chose the Replace option).
I have to go one by one to check in the objects
You don't have to check in every individual object - in Repository Manager open the Versioning menu and choose the Find Checkouts... option. All the checked out objects will be listed - you can select them and check in all of them at once.

How to exclude particular user for schdule trigger in ccnet while IfModificationExists is true including it and false excluding it with TFS.

I have situation where my project checkin some changes during build. I also have scheduled trigger for build whenever there is change in modifications in TFS/VSTS source control. My problem is that, it automatically scheduled triggers build because of changes made during last build Hence, I am unable to achieve what I want to achieve. I want to make sure build is triggered when there is changes for scheduled build by development team and not my own build. Any idea how can i exclude myself while CCNET is detecting changesin TFS/VSTS source control?
What file or files are being modified and checked in by the build server? If the checkins are being made to a single location, you can limit the areas that ccnet monitors. You may need to use the Multi Source Control Block.
Use the Filtered Source Control Block which is specifically designed for that purpose

How can a Jenkins build differentiate between a SCM-triggered, and a user-requested build?

I would like my builds to behave differently (a handling script needs to know) if a person requested the build through the UI "build now" button, or if it was triggered by SCM. I don't want to have to provide a checkbox in the UI that the users have to alter - I've already gotten blowback from them about such things. Trouble is, any parameter I set has the same default regardless of how the build is triggered.
You should not really have 1 job with different behaviour. If you need different behaviour set up a job per behaviour. Best bet in your case is to have 2 separate jobs, one for the SCM triggered builds, and one for the manually triggered builds.
There's a plugin to allow you to filter jobs into separate pages (can't remember the name at the moment). You could set all SCM builds on 1 page and manual builds on another, then set the manual build page as the default one on login. Users will only see the jobs you want triggered manually by default, but can still access the SCM triggered builds by selecting the other page.
Could you somehow check the SCM polling log during the pre-build (with a script), and then go from there?