I'm running latest version of TFS 2015 release manager. I have a simple release that includes a "CopyFiles" task. I need to have the "Clean Target Folder" option of the task enabled.
I have three target environments configured. Both are newly created identical Windows servers. The CopyFiles task works fine against the first two servers but for the next environment in the pipeline, when copying to the second server I get the following error:
2016-11-11T21:41:07.4324714Z found 2 files
2016-11-11T21:41:07.4324714Z ##[debug]file:D:/Build/_work/df9f2c4cf/(master) Orchard BTDF/drop/20161111.5.zip will be copied.
2016-11-11T21:41:07.4324714Z ##[debug]file:D:/Build/_work/df9f2c4cf/(master) Orchard BTDF/drop/Unzip.ps1 will be copied.
2016-11-11T21:41:07.4324714Z Cleaning target folder: \\Steatbt02\BizTalkDeployments2\Orchard
2016-11-11T21:41:07.4324714Z ##[debug]rm -rf \\Steatbt02\BizTalkDeployments2\Orchard
2016-11-11T21:41:07.4480915Z rm: could not remove directory (code EPERM): \\Steatbt02\BizTalkDeployments2\Orchard
2016-11-11T21:41:07.4480915Z ##[debug]task result: Failed
There's no sign of errors in the event log.
I created the share "\Steatbt02\BizTalkDeployments2" and granted "full-access" permissions to the account running the build agent. I even tried logging onto the build server and run as for the command prompt using the credentials of the build agent. From this command window I was able to remove the target folder
"\Steatbt02\BizTalkDeployments2\Orchard" - so I can't think why the build agent would have trouble doing the same!
Any ideas what could be wrong, or what extra steps I could take to track down the root cause of the problem?
The problem was the agent queue selected for the problem environment.
Related
I have an established CI pipeline comprising (prior to deployment):
TFS build
JFrog Artifactory for build artifact management
SoapUI and SpecFlow (BDD & itaretive, parameterised) for web service functional test automation
I have no access to our build agent servers and no permission to install anything thereon. Instead, I've added the SoapUI binaries as links to my functional test project; the binaries are pulled from source control in the Get Sources step of every build.
This works okay but it greatly increases the footprint of my test project (and any other test project for which SoapUI would be required), and by extension, the execution time of the build: functional testing will only execute on a small fraction of the builds executed (only if application codebase has changed or sufficient time interval since last full build and test has elapsed).
For these reasons, I opted to remove the SoapUI binaries folder from my test project and instead deploy a SoapUI binaries zip archive to an Artifactory repository. With the addition of a PowerShell script step in my build definition, I can pull the SoapUI binaries as needed and extract to the desired location on the build server. Foolishly, I thought this might be straightforward...
I did manage to push the zipped SoapUI binaries folder to the Artifactory repo, and, in my Development build definition, I did manage to correctly script my PowerShell step to pull the zip archive and extract its content successfully to he same folder in the build binaries directory on the build agent server as it had been located originally.
However, when I execute my build, in the step where the SoapUI tests are executed, on the first test iteration, I see the following error returned to build console:
System.ComponentModel.Win32Exception: The directory name is invalid
I added a PowerShell scripted filtered folder content step before the test execution step in both my Development (new) and my Production (original) builds for comparison. Both show the required 'testrunner.bat' to be present, in the same folder on the build agent server.
The test project itself has been unchanged (except for the removal of the SoapUI binaries folder).
To summarise:
I'm trying to execute SoapUI tests in two builds; in each build, the same test project is used and the SoapUI binaries are in the same location when the test execution kicks off.
One build executes successfully without issue.
One build fails at test execution step, returning error "System.ComponentModel.Win32Exception: The directory name is invalid".
I'm very puzzled by this; insights and SoapUI wisdom most welcome.
Thanks for looking.
Turned out, there was a discrepancy in the directory paths on the testrunner.bat between the builds; a '_' where a '-' should have been
We're having issues with our automated deployment system.
On our own computers, running ng build generates the dist folder. Within the folder, it has the assets as expected.
I have replicated this, on the build server, manually pulling the git repository, and running the "build file" (the build server runs on Windows Server. The build and deploy process is managed via a PowerShell script for convenience).
When our Jenkins server runs the build script, the assets folder is missing from the /dist/ folder, as well as some other files configured in angular.json.
It is also not properly compiling the stylesheets, which I've believe is due to the same root cause.
The issue persists when running the PowerShell script directly from the Jenkins workspace when the shell is run as a system administrator.
The CLI does not produce any errors.
I'm attaching a verbose log, in case this could be helpful.
https://gist.github.com/cf-jola/6cc6cff138da5105f3b10adffb72895f#file-output-txt
Running the script as the system administrator I've ruled out it being a permissions issue. Jenkins is also managing to create other files, such as the
.js files, and the index.html fine.
My workaround right now is to, via the deploy powershell script, to manually copy the assets folder, how-ever I'd love to get rid of this workaround as we're starting to get multiple files in our angular.json > assets section.
For references:
angular.json https://gist.github.com/cf-jola/6cc6cff138da5105f3b10adffb72895f#file-angular-json
deploy script: https://gist.github.com/cf-jola/6cc6cff138da5105f3b10adffb72895f#file-deploy-ps1
Its a bug, in either Node or Angular CLI.
Because we have brackets, ( & ), in the build path, they get encapsulated in square brackets.
This causes the path: C:\Program Files (x86)\Jenkins\... to become this C:\Program Files [(]x86[)]\Jenkins\... and thereby become invalid.
We discovered the issue by using Process Monitor and looking over the events generated during the build process.
We are starting to migrate our old xaml build def's to VSTS web-based build def's. For each branch, we have a debug build def and a release build def. The debug build def is set up as a Continuous Integration build. As a test, I modified one source file and checked it in. The old xaml build def checked out the 1 file and seemed to have built only the project that changed (what we want and expect in a CI build). In the xaml build log I see the following:
<InformationField Name="Message" Value="1 file(s) were downloaded with a total size of 0.29 MB." />
and it ran the build in 3.3 minutes.
In the new VSTS build - I see that it does a "tf get /version:170936" and gets all the files in changeset id "170936":
2018-06-12T15:08:39.8409262Z Checking if artifacts directory exists: C:\BuildAgent\agent2\_work\1\a
2018-06-12T15:08:39.8409262Z Deleting artifacts directory.
2018-06-12T15:08:39.8409262Z Creating artifacts directory.
2018-06-12T15:08:39.8564882Z Checking if test results directory exists: C:\BuildAgent\agent2\_work\1\TestResults
2018-06-12T15:08:39.8564882Z Deleting test results directory.
2018-06-12T15:08:39.8564882Z Creating test results directory.
2018-06-12T15:08:39.8877401Z Starting: Get sources
2018-06-12T15:08:39.9033640Z Entering TfvcSourceProvider.PrepareRepositoryAsync
2018-06-12T15:08:39.9033640Z localPath=C:\BuildAgent\agent2\_work\1\s
2018-06-12T15:08:39.9033640Z clean=False
2018-06-12T15:08:39.9033640Z sourceVersion=170936
2018-06-12T15:08:39.9033640Z mappingJson={"mappings":[{"serverPath":"$/Path/To/Branch","mappingType":"map","localPath":"\\"}]}
2018-06-12T15:08:39.9033640Z Syncing repository: Project Name (TFVC)
2018-06-12T15:08:39.9033640Z workspaceName=ws_1_45
2018-06-12T15:09:06.7318304Z Workspace Name: ws_1_45;a6060273-b85e-4d4b-ac63-3fbbcafc308b
2018-06-12T15:09:06.7630780Z tf get /version:170936
2018-06-12T15:09:21.6070136Z Getting C:\BuildAgent\agent2\_work\1\s;C124440
2018-06-12T15:09:21.6070136Z Getting C:\BuildAgent\agent2\_work\1\s;C124440
2018-06-12T15:09:21.6226405Z Getting C:\BuildAgent\agent2\_work\1\s\.nuget;C158533
2018-06-12T15:09:21.6226405Z Getting C:\BuildAgent\agent2\_work\1\s\Build Scripts;C141602
2018-06-12T15:09:21.6226405Z Getting C:\BuildAgent\agent2\_work\1\s\Databases;C124440
~
~ The rest of branch...
~
and then seems to rebuild all projects taking 13.2 min to run, almost 10 minutes longer than old xaml build.
Am I missing something with the new build def? I do not have the "Clean" button checked in the VS Build task. I do have a build.clean variable but it is Blank by default - sometimes we want to clean so we just can set it to "all" at queue time.
Clicking about on the web shows the following MS VSTFS version: 15.105.25910.0
Any help is much appreciated.
For multiple build agents, even though you have not checked Clean checkbox of the VS Build task, and the clean option in the Repository is set to "false".
Since the agent is randomly picked, it may not contain your source code before. That's why you see that TFS does a tf get /version:170936 and gets all the files in changeset id "170936" and also build all projects.
For Multi-configuration in Options tab of build definition. Please refer the official Article: How do I build multiple configurations for multiple platforms?
After that, it will split configurations to multiple builds during the build.
And ow that your build definition successfully builds multiple configurations, you can go ahead and enable parallel builds to reduce the duration/feedback time of your build. You specify this as additional option on the Options page:
Take a look at this post Building multiple configurations and/or platforms in Build 2015
To narrow down if the issue is related to multiple build agents, you could also send TFS build to a specific agent by demand, and queue the build multiple times with clean=false in the same build agent, it should have built only the project that changed(CI).
i'm using TFS2015 and vnext builds to build projects and sln files with build controller
in projects or slns we use robocopy command to copy dlls from builded solution to other folders but sometimes this job done and vnext build passed successfully and sometimes robocopy command can't copy dlls and failed with error
is there anyone solved this problem, can help me ?
1-my build agents run with Network/Service User
2-robocopy command error exited with code 8.
Error 8 from Robocopy means that some files or directories could not be copied at that moment. Since you are saying that the command sometimes succeeds, more likely is either a specific time related issue, or probably the files are being used by some other process at the time when the command is executed. In both cases you could try to execute the same robocopy command manually several minutes later, and see if it will fail again. You could add a /v option in your robocopy command (and possibly /LOG), and verify if there is more descriptive error in the log file afterwards. Also, when it fails, is the environment same as the one, on which it succeeds?
Building my solution succeeds, but the build fails upon copying from the build to the drop location. I get an error like this
TF270002: An error occurred copying files from 'E:\Workspace' to '\\server\drop location_20101026.25'.
Details: Access to the path '\\server\drop location_20101026.25\_PublishedWebsites\website\bin\somecompiled.dll' is denied.
This is a part of a continuous integration build (as well as several other types of build that I've tried). This is a copied build definition from a definition that has worked for several months now, running on TFS 2010.
Yep, I was right, I did this myself by putting the copy to drop location task in the parallel foreach loop, resulting in the task being done 3 times, and causing my problems.