So I'm trying to get the custom build task directory name from powershell when executing a custom build task.
The purpose is that I want jshint to run on build time, and I've got it doing so, but the .jshintignore file needs to know a relative path to exclude files or folders.
So I need be able to get that path at runtime in order to know how many "../" to add on to the excluded files for the minmatch engine, which is what jshint uses, to match them.
I can, of course, hard code it, but that's really not what I'd prefer to do.
Yes, you can use the Agent.HomeDirectory variable.
Agent.HomeDirectory | AGENT_HOMEDIRECTORY | The directory the agent is
installed into. This contains the agent bits
The tasks folder will be $(Agent.HomeDirectory)\tasks(TaskFolder)\
Related
Is it possible include arbitrary files (in this case a .csv) from a TwinCAT project direct to the Boot directory of a PLC?
By using PATH_BOOTPATH in the file open/read FBs it is possible to load files from this directory in a convenient manner regardless of whether using a CE or Windows deployment, However deployment of files to this location seems to be the sticking point.
I know that a copy of the project code is included within the CurrentConfig<Project>.tpzip file, but this file is not easily accessible from code, or updateable.
I've found the 'Additional Files' section within the system configuration, but it makes little sense.
Adding a file from inside the project as a 'Relative' path doesn't seem to do anything
Adding a file from inside the project as an external path includes the file (via symbolic links?) in the 'CurrentConfig.tszip' file, which has the same issues as the .tpzip
Adding an external file as an external path again includes the file inside of the .tszip.
I'm willing to accept that this might not be possible, but it just feels odd that the PATH_BOOTPRJ and PATH_BOOTPATH roots are there and not accessing useful paths.
Deployment
To quote Beckhoff:
Deployment is used to set up commands that are to be executed during the installation and startup of an application.
The event types are essentially at what stage of the deployment process the command is performed, where the command can either be copying a file or execution of a script/program.
Haven't performed extensive testing but between absolute/relative pathing and execution this should solve nearly all issues with deployment configuration.
What is the proper way of delivering temporary build-time assets using nuget?
I am making a nuget package with a single file, which dependent projects require during the build phase. I would like the content of the file to be copied to obj\$(Configuration) folder inside a dependent project before proceeding with the rest of the build. Of course, the obj folder is temporary, so I would like my file to be copied there again as part of the next build if obj gets cleared out.
I tried contentFiles approach described here. This takes care of packaging my file inside nupkg file, but I was unable to set it up so that my file gets delivered (and re-delivered) to obj\$(Configuration).
You're looking for NuGet's MSBuild extensibility. Unfortunately it means you'll need to learn a bit about MSBuild if you don't already know it. I recommend running msbuild -bl or dotnet build -bl, which will create a msbuild.binlog file, which you can view with the msbuild structured log viewer.
One option is to have a target that creates the file in the intermediate output directory at an appropriate time (probably need to use BeforeTargets). You could use the Inputs and Outputs attributes to have msbuild do incremental build checks and skip copying when it doesn't need to, possibly making the build a little faster.
However, unless the file is has dynmanic content, copying the file is a waste. it's just going to be included as an item in another part of the build process. So, if it's static content, you could just create the relevant item in your targets file from your package's extracted directory, and then it's just as good as if it was copied to the intermediate output directory, without wasted time and duplicated disk space.
For example, there is TF_BUILD_SOURCESDIRECTORY environment in TFS which we can use in Post-build Powershell scripts to know the sources directory (where TFS has dumped the source code at build server during build).
That means, this can return us something like - "C:\Builds\3\MyProject\MyApplication.UAT\src"
Now, I would like to know the location of "bin" folder (which usually will be - "C:\Builds\3\MyProject\MyApplication.UAT\bin" in above case). I can always predict that using string replacements, but I would prefer to use Environment variable if there is any.
Do anyone know the environment variable to get the "bin" folder path in build definition?
TargetDir should be available after the msbuild task as been run.
Will give you something like the following for an console applicaiton.
$(TargetDir) "C:\\Playground\\Sln\\prj\\bin\\Debug\\"
or something like this for a web application.
$(TargetDir) "C:\\Playground\\sln\\prj\\bin\\"
This isn't an environment variable but rather an msbuild variable which I belive is what you are after.
Ok, I found it myself from a bit more research on MSDN..
there is an environment variable for this in TFS named as - "TF_BUILD_BUILDDIRECTORY". This variable can be used in TFS build (post-build or pre-build powershell scripts) to know the location of build folder on build server
I need to copy a few files into the App's Resources directory during debug builds. I am thinking about using build rules but don't know how to determine if the build is a debug build. I do have a compiler option of "DEBUG" set.
You can use a Run Script build phase to do the copying. All build settings applied when building the target are available via environment variables in your script.
You can determine what configuration is being built via the CONFIGURATION environment variable; you can look at other environment variables like BUILT_PRODUCTS_DIR to determine where to put your resource. If you specify your Run Script build phase's output correctly, it will only be run when the output needs to be brought up to date, not every time you build.
More information on Run Script build phases is available here: Xcode Build System Guide: Build Phases: Run Script Build Phase
The same kind of thing can be done with script build rules, which is useful if you have multiple resources you want to apply this to: You can create a script build rule that matches your extension (e.g. *.myresource) and use the build settings and input files that are passed to your script via environment variables to do the actual copying. If you specify your build rule's output correctly, it will only be run when its input is newer than its output, not every time you build.
More information on script build rules is available here: Xcode Build System Guide: Build Phases: Build Rules
As above really, I have some integration tests that use files from a relative file path. To help picture it here is the file structure:
/Dependencies
/VideoTests/bin/release/video.dll
/SearchTests/bin/release/search.dll
/OtherProjects
The GUI is running the tests from the root, however when TeamCity runs the tests it is running the tests from each test dlls bin directory. Now I don't mind which one I can get to follow the other but I do need them to be the same otherwise my relative paths just won't work!
Any ideas?
P.S. Using TeamCity 5.0 and NUnit 2.5.
You probably don't want to rely on CurrentDirectory. I'd suggest reading the doc, but the main point you'll want to take away is that the CurrentDirectory is where the .exe was started from: it could be any path in the system. For example, let's assume your users add your .exe (or whatever .exe uses your DLLs) to their path. They could then navigate to c:\foo\bar and start the .exe from there, which would set the CurrentDirectory to "C:\foo\bar" and you may not be able to deal with that.
I think it would be preferable for you to rework whatever you're doing so you don't rely on CurrentDirectory. What problems are you encountering by relying on CurrentDirectory right now?
Have you made sure that both TeamCity and NUnit are using the same working directory when starting the application?
And if they aren't, you could adjust the current directory in the test code.