Correctly reusing a variable for folder in build steps.
I have a build which has two steps. The first executes some Powershell, creates a folder (on agent) with a date/time, to be used for downloads:
$DLFolder = New-Item -ItemType Directory -Path "C:\PATHTO\AppDownloads\$((Get-Date).ToString('yyyy-MM-dd_HH-mm-ss'))"
Write-Output "##teamcity[setParameter name='DLFolder' value='$DLFolder']"
Then the second kicks of the build (which runs some Robot tests).
python -m robot --variable ENV:qa --variable DLFOLDER:%DLFolder% --console quiet --outputdir %teamcity.build.checkoutDir%\results --noncritical non-critical -i DL --reportbackground green:yellow:red %teamcity.build.checkoutDir%\Tests\BLAH
in Edit Parameter, in parameters, the Configuration Parameter has settings of
Name - DLFolder
Value - %DLFolder%
Builds are working, but I don't believe the passing of parameter is correct, as this message is in the log:
Parameter "DLFolder=%DLFolder%" is not fully resolved, using as is.
What is the correct method of passing the DLFolder for reuse in the build?
Please sign in to leave a comment.
Hi,
You shouldn't be using DLFolder with value "%DLFolder%. This would be a circular reference and teamcity has to discard it. You mention that the builds are working. Can you confirm whether they are using the proper folder? Regarding the parameter, you can see which value is being taken by the build if you check the build log, parameters tab. The final parameters will be displayed there.
I've edited the DLFolder to avoid the circular reference:
Write-Output "##teamcity[setParameter name='DLFolder']"
Checking in parameters for that build though, User Defined Configuration Parameters has:
DLFolder with a Value Passed to Build of %DLFolder%
however, in the section for Actual Parameters on Agent DLFolder is empty.
I've checked on the agent and download location has been created, but not utilised.
Hi,
I might not have expressed myself properly. In the build configuration, parameters section, you mentioned having defined DLFolder as %DLFolder%. That's incorrect. The service message needs to have a value or it will take the default of empty.
So, to check - should the service message part still be:
"##teamcity[setParameter name='DLFolder' value='$DLFolder']"
and then change the build configuration, parameters section? And if so, how exactly should that be in that section?
Yes, that would be the correct approach. In the parameters section you should provide a sane default.
As that folder name though is being created dynamically (it has a date/time string, created at startup), how can a sane default be created in this instance?
I had wished to - create the folder, saving it against the PowerShell variable, then pass that into team city.
That sounds fine, and a sane default can be a fallback in case there is any issue with the date (shouldn't be, but just in case).
Is there a particular reason to have the folder created in a separate step? It feels like it would be better to create it when needed, otherwise if the initial script fails you could be creating empty folders for nothing.
No, possibly creating the folder after would be possible, but as the Robot tests are run in the second build step, they need the download parameter to exist for use. Is there a means of passing it from a step coming after the tests being run?
Using the setParameter properly should work. Did you try again after fixing the issues I mentioned?
No, the download is still defaulting to the standard folder on the runtime agent.
Parameters tab has this:
Could you check that the powershell script generates the appropriate value? I've been testing this and for all I try it works just fine on my end (I have tried just your initial command with your own same default value of $DLFolder).
You might want to double check that you have permissions to create the folder. I've created the folder locally in the working directory instead, but if for some reason your directory fails to be created, that might lead to some issues.
The folder is created, that isn't an issue (I remote onto the machine and check this).
This is pretty strange.
As a next step, I'd recommend doing a couple tests:
Set up a build configuration with only your powershell script, exporting the variable. Run it and double check that the build results, parameters tab, has picked up the new value for the parameter.
If something goes wrong here, the value is not being assigned to the parameter properly. I'm not exactly sure what could produce this, this is thoroughly tested.
Next step, set up a second build step (on the same configuration) after the initial script, where you try to reuse this parameter. Simply set up a command line runner and run "echo %DLFolder%" within it, to validate that the value can be picked up.
If something goes wrong here, the value is being assigned properly, but is not being picked up by the next step. This is the exact scenario I have tested myself and it works in my environment. It's important to note that this are build steps within the same build configuration, not different build configurations on a separate chain. That requires a different syntax.
The folders are created within the step - I think perhaps the returning them to the test runner is somehow the issue:
[Step 1/2] ##teamcity[setParameter name='DLFolder' value='C:\CustomFilder\AppDownloads\2019-05-17_09-13-41']
the issue was that this line should pass the created value into an env. variable.