I am trying to set up an API-key to be a global variable that is accessible across all of my TFS2015 Builds. Since TFS2015 seems to lack this feature, I am attempting to use a system environment variable on the build server that is then referenced in the build definitions.
According to Microsoft's documentation, this should be possible. So I have set up a system variable (call it APIKey) on the build server and referenced it within the arguments of a build step using the standard syntax (i.e. "ApiKey=$(APIKey)"). However, instead of replacing the variable with the API-key in the system variable it is trying to use $(APIKey) as the value and causing the build to fail.
It also occurred to me that this custom environment variable would instead be set somewhere in the build agent folder itself but, after some poking around, I'm not sure where or how I would do that.
Are either of these things actually doable?
Following are my steps to achieve this:
Create a system variable on build agent machine:
Restart the build agent machine.
Use the variable in build definition. Here I use cmd task as an example and use the $(testvar) as its argument:
The task will read the value from system variable as following:
Related
I am wanting to measure the time it takes for my C++ video processing program to process a video. I am using CLion to write the program and have Cmake set up to compile and automatically run the program with a test video. However, in order to find execution time I have been using the following command in the MacOS terminal:
% time ./main ../Media/test_video.mp4
Is there a way for me to configure Cmake to automatically include time in the execution of ./main to streamline my process further?
So far I've tried using set(CMAKE_ARGS time "test_video.mp4") and some command line argument functions but they don't seem to be acting in the way that I'm looking for.
It is possible to use add_custom_target to do what you want. I'll not consider this option further as it seems abusing the build system for something it wasn't designed to do. Yet it may have an advantage over using CLion configuration: it would be available to be used outside of CLion. That advantage seems minor: why not run the desired command directly in those contexts?
The first CLion method would be to define an external tool which run time on the current build target. In File|Settings...|Tools|External Tools define a new tool with /bin/time as program, $CMakeCurrentProductFile$ $Prompt$ as arguments. When choosing that tools (in Tools|External Tools) it will now prompt you for the argument and then run /bin/time on the current target with the provided arguments. Advantage: you don't have to define the tool once, it will be available in every project. Inconvenients: the external tools are available in every project, thus it doesn't make sense to be more specific than $Prompt$ for the arguments and the working directory; it isn't possible to specify environment variables, it isn't possible to enforce the need of a build before running the command.
The second CLion method would to be define a Run/Debug Configuration. Again use /bin/time as program (chose "Custom Executable"), specify $CMakeCurrentProductFile$ as first argument (here it makes sense to provide the other arguments as desired, but note that $Prompt$ is still a valid choice if needed). Advantages: it makes sense to be as specific as needed; you have all the feature of configurations (environment variables, input redirections, specifying actions to be executed before the execution). Inconvenient: it doesn't work with other CLion features which assume that the program is the target such as the debugger, the profiler, ... so you may have to duplicate configurations to get them.
Note that the methods aren't exclusive: you can define an external tools and then add configurations for the case where it is more convenient.
I'm installing a software extension for VS2017 which requires me to create a batch file in order to set the 'TargetVisualStudioEdition' environment variable, in my case the variable should be set to Community.
What I did so far is to crate the following simple batch file:
set "%TargetVisualStudioEdition%"="Community"
Once I run it I receive:
set ""="Community"
Then, when I run the installer the installation stops because the environment variable has not been set.
Am I missing something?
don't think you need the %s wrapping the variable;
just do set VARIABLE = value
the %% is just to reference the variables.
if this variable will be shared among processes, use setx
When creating a vNext build on TFS 2015 you can define variables, which are then used in build steps, and can also be used as environment variables in scripts the build runs.
The build I am working on runs scripts that pulls files from mapped locations, so it would be great if I could define a variable and use it in a mapping so that for example, if I update a reference in the project the build is building, I can simply update the variable with the new location and have the repository mappings and scripts all pull correctly from the new location without having to make the change in multiple places.
I have tried doing this by setting up the variable and mapping as follows,
But this generates an error when you try to save the build complaining that there are two '$' characters in the mapping. Is there way to do this or is this not currently possible?
This has been causing me havok for quite a while as well.
For starters, there is a uservoice request for this feature. You can add your votes and input here to get Microsoft to allow this feature: https://visualstudio.uservoice.com/forums/330519-team-services/suggestions/14131002-allow-variables-in-repository-variables-and-trigg
Second, we've developed a workaround that gets us most of the way there. It's not perfect, but it might be useful to you if you're comfortable with the tradeoffs or can work around the deficiencies.
Start by turning off the "Label Sources" option of the build and mapping the Server Path field to you base build. You'll want to add a custom variable to the Build Definition to tell the build instance what TFS location to pull from. For example, we have a base project and then multiple branches from the project, so our source is structured like this
$\Team Project\Project1
$\Team Project\Project1Branch1
$\Team Project\Project1Branch2
$\Team Project\Project1Branch3
and we create a variable named "Branch" that we can set to "Branch1", "Branch2", and so forth.
When we want to build the base project, we leave the Branch variable blank when launching the build. For branch builds, we set it to the name of the branch we want to build.
Then our build steps look like this
Remap Workspace Folder to Branch Folder
Get Files for Specified Branch - We have to do this manually after
remapping our workspace
Compile the Source in the Specified Branch
Publish Build Artifacts from the Specified Branch
Label the Code of the Specified Branch Manually
The Remap task runs the command
tf workfold "$/Team Project/Project1$(Branch)" "$(build.sourcesDirectory)\$(Build.DefinitionName)$(Branch)"
The Manual Get task runs the following command
get /recursive /noprompt "$/Team Project/Project1$(Branch)"
The build uses the Branch variable to point to the correct location of the solution file for the specified branch
$(build.sourcesDirectory)\$(Build.DefinitionName)$(Branch)\SolutionFile.sln
The Publish Artifacts task uses the Branch variable in both the Contents field and the Path field
Example in Contents
**\$(Build.DefinitionName)$(Branch)\bin
The Label Code task uses the following command
tf label "$(build.buildNumber)" "$/Team Project/Project1$(Branch)" /recursive
The downside of this setup is that you don't capture Associated Changes and Work Items to your subsidiary branches as the Server Path field is always set to the main location. This may not be an issue if you always merge from your branches to your main location prior to launching a build meant to go to production. What you can do to compensate for this really depends on your use case.
With some tweaking, you could use this same format to specify full paths as well if you needed to.
It's impossible. Just as the error message mentioned: there are two '$' characters in the mapping. Which means your application's path shouldn't vary from build to build.
Mappings on the Repository page are used to specify source control
folder which contains projects that need to be built in the build
definition. You can set it via clicking the Ellipsis (...) button,
however, you can't include variables in the mapping path.
There is a similar question: Variables in TFS Mappings on Visual Studio Online Team Builds
I would like to change the dynamic variable ${selected_resource_loc} such that I get rid of the extension (and can add another one).
The purpose is to build the current selected file, but therefore I don't need the .cc-file in my command but the .o-file with the same name.
Detailed description:
I have a customized make command (lets say make) and would like to execute make selectedFileName.o, where the current selected file in eclipse is selectedFileName.cc. (I put the command as build command in project properties -> C/C++ Build.) With variable ${selected_resource_loc} in behaviour tab I get make selectedFileName.cc.
I solved my problem by writing a skript where I modify the ${selected_resource_loc} and included it via external tools in eclipse.
I want to build a library with waf, but install it under a different name than the target name. It seems you can do
bld.shlib(..., install_path='${PREFIX}/lib')
but I need to be able to do something like:
bld.shlib(..., install_as='${PREFIX}/lib/xyz')
Also, bld.install_as() wont work, as it doesn't seem to accept a task as a target, and I can't figure out how to turn a task into a node representing the target, so the following doesnt work either:
tgt = bld.shlib(...)
bld.install_as('foo', tgt)
Or alternatively, I need to be able to disable the "lib" prefix that is automatically added to library names, but only for this one library - not for all them during the build, e.g. something like:
bld.shlib(..., libprefix='', install_path="${PREFIX}/lib/")
I know you can set shlib_PATTERN as well, but that seems to affect all libraries under the current environment. We have a pretty complicated build that uses a lot of different environments for building debug/release concurrently, so just cloning the current environment and changing the flag doesnt work either, because it clones the default environment, not the one the target will eventually be built under (because we clone the targets for each environment during build time).
Any thoughts? Thanks!
You can do this:
hello_lib = bld.shlib(
includes='/usr/include/python',
source='a.cpp',
target='hello',
uselib='BOOST_PYTHON',
vnum='0.0.1')
hello_lib.env.cxxshlib_PATTERN = '%s.so'
This code changes naming pattern for only one task.
There are two keyword arguments you can use: "name" and "target". "target" is the name of the file create while Name is the name of the target when using the "--target" argument. Confusing, but here is an example:
bld(features=['cxx','cxxshlib'],
source=src,
includes=inc,
target='OutputName',
name='NameOfTarget',
use=libs,
install_path='${PREFIX}/lib/MyLibs
)
waf configure build install --target=NameOfTarget --prefix=/home/Brian
This creates a shared library "libOutputName.so" and installs it to /home/Brian/lib/MyLib