I am trying to use the this Build Agent Folder for my build definition...
$(SystemDrive)\Builds\$(BuildAgentId)\VPB
... but I get the following error.
TF10122: The path 'c:\Builds\$(BuildAgentId)\VPB' contains a '$' at
the beginning of a path component. Remove the '$' and try again.
I need to include something to denote the agent because I have two build agents on the build server.
I am trying to keep the path short, because InstallShield has unreasonably long path names for merge modules (too many subfolders and adds GUIDS to the ends of everything).
Any idea why this doesn't work?
Ensure that your Build Definition and Build Agent working directory are setup correctly.
Setting up build agent working directory and build definition working directories
Related
I’m setting up an automated build in VSTS that will FTP the published files to my server.
I have this working but the way I’ve achieved it, I feel is hacky and non-sustainable.
the process as you can see from the screenshots will publish the artefact which consists of a readme, cmd file and a zip containing all my publish files and then I extract the ZIP with the very explicit location below.
$(Build.ArtifactStagingDirectory)\temp\Content\d_C\a\1\s\IntermittentBug\IntermittentBug\obj\Release_EukHosts\Package\PackageTmp
I’m using a hosted build server in VSTS but as the path contains
d_C\a\1\s\
I assume this will change in time. What I need is a variable to cater for this path so it will always succeed.
How can I update this to make it more efficient and sustainable?
First, as jessehouwing said that the variable is called Build.SourcesDirectory.
Regarding the path structure, the simple way is specifying /p:PackageTempRootDir="" msbuild argument in Visual Studio Build task to remove the source path structure, then the path will be like Content\D_C\PackageTmp.
On the other hand, you also can publish the web app through File System mode.
This variable is caught in a predefined variable called Build.SourcesDirectory. see the complete list of predefined variables here.
In your batch or powershell scripts this variable is available as a environment variable called %BUILD_SOURCESDIRECTORY% / $env:BUILD_SOURCESDIRECTORY.
I have created build definition which runs successfully. Now I want to create a release definition on the successful build, for which it is asking for artifacts.
When I tried browsing "Drop" folder, I found it empty.
Below are the images from Copy Files step and Publish build artifacts step.
I also tried instructions from The item MY_ARTIFACT_NAME in container XXX could not be found
But no luck. Please help.
I believe that you should use $(build.sourcesdirectory) (or a path relative to) as the source folder if you want to copy files which are not checked in.
Also, from the documentation of the Copy Files step
The pattern is used to match only file paths, not folder paths. So you should specify patterns such as **\bin\** instead of of **\bin.
Try changing the contents pattern to **\bin\** and see if that helps.
The gulp files installed in a asp.net5 web project use the maximum path length. If you have a project path with more than a few characters long, the folders cannot be deleted.
This post refers to how to build using a short temp directory:
"Path too long" when publishing asp.net 5 from Visual Studio 2015
The question is, how do you easily remove these files when you need to clean up, restore, or archive a project?
Simple answer is file system basics. Create a directory in the same root as your project and give it a really short name (like "c:\t"). Then move all the files in node_modules there. then delete them.
I hear ms is working on a more workable gulp folder structure.
The reason you are hitting the NTFS file, path and name length limit of 255 characters is because of NPM nesting of package dependencies, which is a known Node issue on the Windows stack. You should try to update NPM to the latest version, 3.0 or greater, where they now use a flat approach to handle package dependencies. This will help you avoid the problem "unable to delete" because you will never have paths beyond 255 characters.
Perform the following:
1) Update NPM on your machine, by updating to the latest version of Node (download from https://nodejs.org/download).
2) Update Visual Studio 2015 External Web Tools to point to the folder with the new tools. (Tools-Options-Projects And Solutions-External Web Tools).
Usually:
C:\Program Files\nodejs"
or
C:\Program Files (x86)\nodejs"
Make sure this is the top option on the list of paths.
3) (On automated build) Make sure that Visual Studio does not use the packaged NodeJS version when building your project by passing in the following parameter to MSBuild.
/p:ExternalToolsPath="C:\Program Files\nodejs"
or (x86) if applies:
/p:ExternalToolsPath="C:\Program Files (x86)\nodejs"
After doing a lot of head hunting, I found about robocopy and this command has been my friend since then. I use the following steps to remove a file or folder when the windows path is too long
Create a folder anywhere in your system to use as a source (leave it empty).
Take back up from the folder you want to delete (if there is something important)
Open Command prompt
Type the following command. Modify the placeholders to suit your needs.
robocopy C:\path-to-source-empty-folder E:\path-to-folder-you-cant-delete /purge.
Note: If there are spaces in source or destination path in Step 4, the path must be enclosed by quotation marks.
After successful execution of the command, you will get execution report like the following
Everything inside the destination folder will be deleted forever.
You can also type robocopy in command prompt to see other options.
I hope this helps.
I want to set up my HelloWorld intellij-erlang project with all files in the same directory so I can easily switch between IDEA and emacs/vim.
<my-project>/hello.erl
<my-project>/hello.beam
Now, if I configure the output directory to be the same as the source, hello.erl gets emptied as part of the build and the compilation fails.
I assumed it's something to do with copying resources to the output directory, so I've configured intellij-erlang to exclude *.erl from the resources with a !?*.erl pattern, but this does not have any effect, hello.erl still gets emptied before the compilation takes place.
As an experiment, I've also tried using separate src and out directories, and intellij-erlang always copies the *.erl to out irrespective of the resource patterns.
Based on all this, I would conclude that intellij-erlang cannot work with all files in the same directory. Have I missed anything?
Erlang programs should be build on standard OTP directory structure. Build tools like rebar (used by intellij) or erlang.mk build on this conventions. And so should all IDE's.
Intellij does it, just like you notice. And so does Emacs's plugin (that I use and can confirm). I would guess so does Vim's one.
So if you would like to be able to switch easily between your IDE's you should try to keep to this convetion of keeping you source files in src and compiled files in bin (and headers in include).
I want to change the build dir of team city build agent to:
E://MY_PROJECT_SVN
While installing the build agent I set the same but it diaplays C://buildAgent/work in TeamCity web ui due to which my build fails.
My buildAgent.properties file shows
workDir=E\:\\MY_PROJECT_SVN
And buildAgent.dist.properties file shows
workDir=E://MY_PROJECT_SVN
But I get following error when I run team city
Failed to start MSBuild.exe. Failed to find project file at path:
C:\BuildAgent\work\3ac16e0b4e3af05b\Modules\SIM5.sln
Because of wrong working dir
The buildAgent.dist.properties is indeed just an example, but the solution is something you almost had; you need to put this into the buildAgent.properties:
workDir=E:/MY_PROJECT_SVN
Update:
It should be noted that on TeamCity 7.0 the workDir seemingly can't be on a separate disk; it runs most of the way through the build and then fails. However, using a junction to point from the local (default) folder to the E: drive will work. The tempDir can be pointed to a remote disk though.
The file buildAgent.dist.properties is not used, it is just an example. So don't worry about the contents of that file.
What you have set in buildAgent.properties is what matters. What is happening for you is the agent is reverting to the default location for the working directory.
This means that for some reason it is not able to read or parse the buildAgent.properties file. Make 100% certain that the entire file has no errors in it.
https://confluence.jetbrains.com/display/TCD8/Build+Agent+Configuration
Making any change to this file and saving it should cause the build agent to reboot automatically and reload the new config once it has restarted.
http://blog.jetbrains.com/teamcity/2007/10/configuration-files-editing-without-teamcity-restart/
To build on paul-f-wood's answer:
Teamcity 9.1.6 also has the "feature" where the work directory cannot be on a different drive. I tried several permutations of the temp and work dir, and the only ones that stuck were with the work dir on the same drive as the root teamcity folder. However as paul said, using a junction works like a charm.
cmd: rm C:\BuildAgent\work
cmd: mklink /J C:\BuildAgent\work E:\MY_PROJECT_SVN