long time listener, first time caller!
I've spent two days searching for an answer to this so hopefully someone here may be able to help.
I've set up a personal/free VSTS instance and created a project.
One of the first tasks I want to do is setup the build pipeline, so create a new pipeline, define the agent pool as VS2017, connect to my Github repo etc, all of which is fine.
Next I try to add an Agent Job, again choosing VS2017 as the agent. With no other options chosen, if I try to save the build definition I get the following error message (and cannot save it);
The AllowScriptsAuthAccess build option is not supported in API versions greater than 4.0.
Allow scripts to access the OAuth token is unchecked on the Agent job configuration under phases and on the Build/Options tab (slider set to disabled)
I've googled and searched for all sorts of stuff to try and find someone with the same problem but it's almost like I'm the first to discover this - which is highly unlikely!! It has almost driven me to using Bing to search for a solution, but let's not get carried away.
Any ideas or suggestions would be greatly appreciated!
So it turns out that turning off the "New YAML pipeline creation experience" and "New Navigation" under preview features fixes the problem, insofar as I can now create and save a build pipeline without the error.
Also, if you have "Build YAML Pipelines" enabled under preview features for the Organisation, you get the "View YAML" link that I was missing also.
Thanks all for your help. I'd be interested to know the root cause of this still. I'll update the Microsoft support ticket with the same and post back here if they have any insights.
There's an similar issue here:https://developercommunity.visualstudio.com/content/problem/123012/getting-multiconfiguration-build-option-not-suppor.html
Seems the build template was broken. So, you can try with other build templates or starting over with an empty template, then add the needed tasks manually to check if that works.
Besides, you can try below things:
Clean the caches on your client machine, also clean the browser
caches, then check it again. See How to clear the TFS cache on
client machines.
Create a new team project and create a new build pipeline within the
new team project to check if that works
I am assuming this is a bug in the VSTS system and it will likely be fixed soon. But for the time being, I found a workaround:
I was also getting the AllowScriptsAuthAccess error and struggled with it for hours. I don't think any of the configuration settings you mentioned have anything to do with it (free account, GitHub, OAuth token unchecked).
To solve it, I converted the Agent Job to YAML (which is as easy as clicking "View YAML" in the upper right). Save the code to a file named .vsts-ci.yml, and save this in the root folder of your solution. Commit/push the new file, then queue the build. (Note that the conversion to YAML is one-way, so you may want to Clone your build.)
That should get rid of the AllowScriptsAuthAccess error. After that I had to add a few variables, but then it's just a matter of following the error messages.
I hope this helps. Sorry I can't answer this more authoritatively. Please post a comment if I am missing any steps.
I had this issue and it turned out that I didn't have Build Admin permissions in VSTS for the project. Not a very helpful error message for this.
Related
I am investigating a way to automate some of our build processes using Jenkins and HPQC. Currently, we have a process where, once a change to fix a defect has been checked in we set its status to "Fixed" and then reassign defect in HPQC from the individual developers to a team lead.
The team lead is tasked with manually deploying a build for the deliverable to the test environment and when he does this he will then update all of the defects assigned to him this way reassigning them to the test lead, who can assign them to individual testers.
I would like to automate this process where I can. Does HPQC have a web API of some kind? So that a remote system (such as a Jenkins build server) could run a post-build action script to gather a bunch of defect numbers (those included in the build) find each defect in HPQC and then update its status and owner?
There is a REST API for ALM / Quality Center, info is accessible:
http://support.openview.hp.com/selfsolve/manuals
You will have to sign up for an account with HP to access it. Ugh, troglodytes.
Search for "ALM REST API", download and read the newest guide and reference for your version of QC.
(We also use QC at my work. It's pretty damn bad. I should try and convince them to get or build something better.)
The answer above is a good one, I found the reference he mentions, but making use of that is not very intuitive, probably because I am such a newb. For my fellow unenlightened you might want to use another reference I found for how to use the reference :
http://www.consulting-bolte.de/index.php/22-hp-alm/hp-alm-rest-api/115-connect-to-hp-alm-via-java-using-rest-api
The key piece of information for me was that inside all of these class files they give you in the "Example Applications" folder there is a reference to a package :
package org.hp.qc.web.restapi.docexamples.docexamples.infrastructure;
This is just another name for all the files located in the guide in the "infrastructure" subfolder. You do not need to go find this out on github or something.
I just got assigned at my job to figuring out Team Foundation Server as we are switching to it from PVCS. I was messing around with the source control features, trying to get gated check-in to work, as that is something we will be using in my job. I am pretty sure I set up the build definition correctly, as far as I can tell that is, and I turned MSBuild Multi-Proc to false as I have seen suggested online.
My problem is that when I try to check in a file I get an error for every file in my project stating
C:\Builds\1\TFSTestProject\Gated\src\TFSTestPrograms\TFSTestPrograms\{File} Access to the path 'C:\Builds\1\TFSTestProject\Gated\src\TFSTestPrograms\TFSTestPrograms' is denied.
I don't understand why I would have any access denied and I have looked for solutions all over google and have not found anything that has fixed this issue. My server url is just http://localhost:8080/tfs so I should have access to everything (at least I think i should...)
Another thing is that there is no 'Builds' folder on my C:\ drive like in the path they give
I am very confused about this issue and I have no idea how to fix it.
If you have installed a build server the path that it is objecting to is on the build server itself. You should review the installation instructions for the build server and the account used to set up the build server.
Two lengthy to repost but ben day has an excellent TFS installation guide here: http://www.benday.com/BlogFiles/Tfs2012InstallGuide/BenDay-TFS2012-Install-Guide-v1.0.pdf
Make sure that whatever account you configured TFS and, more importantly, the Team Build service to run as, has full control access to the C:\Builds folder.
I have setup a build controller etc and the builds were failing, I have fixed these now and the build failed properly - as in because of an error.
I have fixed the error and checked the code back in but now the code is not being extracted, although sometimes one folder of many is.
I have deleted the code from the build machine and requeued a build but it keeps failing. It complains that it cannot find the solution that I specified as the build solution.
I have checked the check box to build even if nothing has changed.
Have I missed a setting somewhere for extracting the code?
TFS version is 2012 Express
Visual Studio version is 2010 Professional
I had this issue recently with TFS 2012. I think it boils down to this:
In the lastest build definition files, it appears that it performs a Clean task before updating the workspace. This means that if you do something that causes the Clean part of the build to fail, it will never download the new files in order to fix it.
Recently, I was making big changes to my build file and inevitably made a lot of mistakes, I found that if one of these mistakes caused the Clean to break, I had to go onto the Build server and change the file manually to get it working again.
Does this sound like it might be the same issue?
There are several properties in your build definition you can check. I would start with setting the "Clean Workspace" to All to ensure the correct code is being pulled down and built.
There are other checks you can look at as well like the agent set for the build and the "GetVersion" property. Check the below link out. It should be able to help you in more detail.
Define a Build Process that is Based on the Default Template
I've seen the question related to the error message you get from TFS when a workspace is already mapped. The accepted answer for removing the workspace is alright as a workaround, but it's already getting tedious to run a delete command each time this error occurs.
What do I need to change in order to get out of having to use this workaround? I've got two builds (continuous integration and nightly deploy), and need to add at least one more build type. I followed this URL to see if there was a possible resolution there, but I'm not sure I understand it completely.
I am not sure how this is accomplished in TFS 2010, as I have not gotten to work with Team Build in 2010, yet. In 2008, though, if you expand the Builds node in the Team Project and right-right click on either of the builds, you will see a "Manage Build Agents..." option. Click into that, and it will bring up a dialog. One of the things on that dialog is an option called "Working Directory". Do you have the same hard-coded path in both of them?
By default, when you create a new build definition, it provides a calculated folder for this value. This is where the build agent will do the checkout from TFS for the build attempt. The default value is, $(Temp)\$(BuildDefinitionPath), I believe (I am not connected to TFS at the moment).
The article you link to is basically saying that you should include either that $(BuildDefinitionPath) value or the $(BuildDefinitionID) value as part of that path in that dialog so that the two builds do not try to use the same workspace. Changing the working folder to include one of those values should resolve your issue, going forward.
I have a Team Foundation Server 2008 Installation and a separate machine with the Team Build service.
I can create team builds and trigger them manually in Visual Studio or via the command line (where they complete successfully). However check ins to the source tree do not cause a build to trigger despite the option to build every check in being ticked on the build definition. Update: To be clear I had a fully working build definition with the CI option enabled.
The source tree is configured is a pretty straight forward manner with code either under a Main folder or under a Branch\branchName folder. Each branch of code (including main) has a standard Team Build definition relating to the solution file contained within. The only thing that is slightly changed from default settings is that the build server working folder; i.e. for main this is Server:"$\main" Local:"c:\build\main" due to path length.
The only thing I've been able to guess at (possible red herring) is that there might be some oddity with the developer workspaces. Currently each developer maps Server:"$\" to local:"c:\tfs\" so that there is only one workspace for all branches. This is mainly to avoid re-mapping problems that some of the developers had previously gotten themselves into. But I can't see how this would affect CI.
UPDATE: Ifound the answer indirectly; please read below
Ok I have found the answer myself after several dead ends. In the end I fixed this unintentionally while fixing another issue. Basically we had just turned on the automatic execution of unit tests for our builds. The test would run sucessfully but then immediately the build would bomb out with a message saying it was unable to report to the build drop folder.
What was happening was that while the Build service runs under one account and has a set of rights; some of the functionality is actually driven through the TFSService account. fter wading a heap of permissions I had my tests being reported. Then I noticed that builds had started to trigger on check-ins; I can't tell you exactly which permission fixed this but hopefully this answer will at least set people down the right path.
One other note a few of the builds started failing due to conflicting workspace mappings - this was a separate issue that I resolved by deleting some obsolete workspaces using the Attrice Sidekicks for Team Foundation tool.
Hope this helps somebody else.
Select your team project from team explorer, then right click on the Builds folder. Select a new build definition and then select the trigger tab. Move the radio button to "Build each check-in (more builds)"
More info can be found here
MSDN How to: Create a Build Definition
Are there any errors in the log on the TFS application server? Anything that indicates that it tried to fire but failed?