I'm using Jenkins with Octopus plugin to create Release in Octopus. This works nicely. However, when in Octopus, more specifically in my first 'Script' step, I can't get hold of the Release package. Only variable I seem to be able to get is:
$OctopusParameters["Octopus.Release.Number"]
What I need is original path for that same Release. My script step in powershell script unpacks nuget package, adds an extra level/folder, zips it, before deploying to an API. If I, in Octopus step, specify "Referenced package" (sourcepackage) then Jenkins will not build it's Post-Build step and complain that "sourcepackage" is missing. I would like to get original path for my package like this:
$OctopusParameters["Octopus.Action.Package[sourcepackage].OriginalPath"]
But I can't find a way without "Referenced package", and if I use it Jenkins will not build. :(
I ended up doing a work around. I added Octopus variable "FeedPath" pointing to "D:\Octopus\Packages\Spaces-1\feeds-builtin[packagename]". In powershell I simply combined "FeedPath" with Release number to get full nuget file path:
$packagepath = $OctopusParameters["FeedPath"] + "[packagename]." + $OctopusParameters["Octopus.Release.Number"] + ".nupkg"
I've used the following to get the installation path for the package: Octopus.Action[Name of Process step].Output.Package.InstallationDirectoryPath. To get the compressed package prior to installation, I assume something similar can be used. Here is a link to the output variables: https://octopus.com/docs/projects/variables/output-variables
Related
I have multiple .csproj files in my git source folder and its subfolders. I want to create NuGet packages for all of them. If I understand things correctly, I should add NuGet Packager build step and configure its Path to csproj or nuspec file(s) to pack to be
**\*.csproj
But no packages get created when I run my build.
By the way, if I manually select some 'csproj' file using "..." button and run build then package for it will be created.
Could anyone explain why I cannot use **\*.csproj matching pattern to create packages for all projects in my source directory and its subdirs? Is there any limit for nesting level or something? At least I have couple csproj files on maximum nested level 4-5 counting from the source folder...
p.s. I know there was a similar bug about Exclusion pattern not working for vsts build so I wonder if it's a related issue?
See my build configuration and log of my NuGet Packager and NuGet Publisher build steps where D:_work\3\s is the folder on a build server where it cannot find csproj files. Although I can see files there, for example the first is on D:_work\3\s\Source\Product\Components\Folder1\MyProj1.csproj, the second on D:_work\3\s\Source\Product\Components\Folder2\MyProj2.csproj, etc...
The level of nesting should not be an issue. I was able to setup a test project with 3 Projects at various levels and the single NuGet Task created a NuGet package for all of them.
Here is the configuration I used (It is the default configuration at this point in time). This was done using version 2.x of the task, so if you are using an earlier version you may want to upgrade.
You can also watch exactly what is happening during this step by setting system.debug = true when you queue the build. After you do this, you can look into the log for the Nuget Pack step and you should see it iterating through all of your directories and sub-directories and flagging those that match. Here you can see that it found and then continues to pack these 3 projects.
Post your detailed setup and log here if you still need additional assistance.
I had a similar issue. The NuGet Pack task finishes successfully, but didn't create a NuGet package.
In the task logging (when running with debug=true) I see the following:
...
##[debug]found 8037 paths
##[debug]applying include pattern
##[debug]0 matches
...
The NuGet Pack task doesn't create a package because it didn't find any .csproj or .nuspec file. In my case the reason it didn't find any .csproj or .nuspec file is because the work folder of my build agent is set to ".". I found this when analysing the pattern in the logs of the NuGet Pack task.
...
##[debug]pattern: 'D:\Agents\agent_1\.\123\s\*.nuspec'
...
The fix for this issue is changing the workFolder in the .agent file of the build agent. You can find this in the root folder of the build agent (e.g. D:\Agents\agent_1\.agent). Originally this was:
{
"agentId": 48,
"agentName": "agent_1",
"poolId": 3,
"serverUrl": "<TFS url>",
"workFolder": "."
}
And you have to change it to
{
"agentId": 48,
"agentName": "agent_1",
"poolId": 3,
"serverUrl": "<TFS url>",
"workFolder": "D:\\Agents\\agent_1"
}
Be sure to restart the build agent windows service after changing this file!
Hope this helps :-)
I've just started trying to configure a CI/CD process using Visual Studio Team Services, with a view to having a gated check-in process which then automatically packs and pushes the output to a private NuGet Feed. I'm successfully getting through the "Get Sources" task which exists natively in the build definition, however my package task is failing at this stage:
d:\a\_tool\NuGet\4.0.0\x64\nuget.exe pack
d:\a\1\s\Core\Core\Core.csproj -NonInteractive -
OutputDirectory d:\a\1\a -Properties Configuration=$Release;OutDir=$(OutDir)
-Symbols -version 1.0.0-CI-20170811-095629 -Verbosity Detailed
NuGet Version: 4.0.0.2283
Attempting to build package from 'Core.csproj'.
MSBuild auto-detection: using msbuild version '14.0' from 'C:\Program Files (x86)\MSBuild\14.0\bin\amd64'. Use option -MSBuildVersion to force nuget to use a specific version of MSBuild.
NuGet.CommandLine.CommandLineException: Unable to find 'd:\a\1\s\Core\Core\$(OutDir)\Core.dll'. Make sure the project has been built.
Essentially, the 2nd line of the log demonstrates that my project file is in d:\a\1\s, however the output is directed to d\a\1\a - not the same place. The instruction to NuGet to package my file then looks in the correct location (d:\a\1\s), but the file isn't here.
I understand that I can specify a Package Folder within the build definition, however I've not changed this from the default ($(Build.ArtifactStagingDirectory)) - I expect this to work natively, but for reasons I can't explain, it's not.
Is there a token or wildcard I can provide in an additional build property that will rectify this? I've taken the guidance of the first posted answer in here and changed $(Build.ArtifactStagingDirectory) to $(Build.Repository.LocalPath), which gets me much closer to the goal as the error now reads -OutputDirectory d:\a\1\s\... - I've tried manually putting a variety of sensible paths no the end of this, but the error persists.
Refer to this article. It has the build variables for the TFS/VSTS environment.
$(Build.ArtifactStagingDirectory) itself refers to the \1\a folder. You might want to try the $(Build.Repository.LocalPath) variable.
Not a 100% if it would work, but might as well try.
The issue is related to OutDir=$(OutDir) instead of OutputDirectory.
The OutputDirectory specifies the folder in which the created package is stored and the OutDir specifies the build output, but the project need to be built before NuGet pack task, so you need to add Visual Studio Build task or related to build project.
You can leave Additional build properties box blank to use default output per to configuration, because you just need to know the package stored path to push package to remote feed.
If you want to change build output, you can specify /p:OutDir msbuild argument to change build output location. For example:
Visual Studio Build task (MSBuild Arguments: /p:OutDir=$(Build.ArtifactStagingDirectory))
NuGet pack task (Additional build properties: OutDir=$(Build.ArtifactStagingDirectory))
BTW, to change package stored location, you need to specify OutputDirectory.
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 am using default build template with TFS 2013, how i can access build parameters (for example, changeset number under build, build directory, source paths, tfs address, agent information...) from powershell script?
Example situation: I want to rewrite all assembly info version informations on Pre-Build script where last part of version number is changeset number, i can probably get changeset with tf.exe commands inside of script but i isn't only thing which i want to know from build agent during build.
I have tried run Get-Variable in script and write it to build but i haven't find any special variables inside of script.
Is there something i have missed or is it so that default build template simply does not pass any variables to powershell runtime during execution?
Figured it out.
Variables are automatically written as environment variables, dir env: showed me that tfs automatically create following variables:
TF_BUILD True
TF_BUILD_BINARIESDIRECTORY C:\WP0\101\bin
TF_BUILD_BUILDDEFINITIONNAME TfsBuildTest2
TF_BUILD_BUILDDIRECTORY C:\WP0\101
TF_BUILD_BUILDNUMBER TfsBuildTest2_20140310.3
TF_BUILD_BUILDREASON Manual
TF_BUILD_BUILDURI vstfs:///Build/Build/6521
TF_BUILD_DROPLOCATION
TF_BUILD_SOURCEGETVERSION C22404
TF_BUILD_SOURCESDIRECTORY C:\WP0\101\src
TF_BUILD_TESTRESULTSDIRECTORY C:\WP0\101\tst
TFS_REG_CRED Build
I'm writing a script that will automatically pack and publish Nuget files to my private repository (a fileshare) and a private symbol server (on localhost).
When I run nuget pack in Powershell I get a string output that contains the file location of both the nuget and symbol package, but as far as I can tell there's no way to programmatically get those paths without parsing the string. The package version is determined by the .csproj itself, so I don't necessarily know which version will be placed in the filename.
Here's the output from the pack command:
Attempting to build package from 'MyProject.csproj'.
Building project 'C:\Users\me\prg\MyProject.csproj' for target framework '.NETFramework,Version=v4.0'.
Packing files from 'C:\Users\me\prg\bin\Release'.
Using 'Myproject.nuspec' for metadata.
Successfully created package 'C:\nuget\MyProject.1.0.0.0.nupkg'.
Attempting to build symbols package for 'MyProject.csproj'.
Building project 'C:\Users\me\prg\MyProject.csproj' for target framework '.NETFramework,Version=v4.0'.
Packing files from 'C:\Users\me\prg\bin\Release'.
Using 'MyProject.nuspec' for metadata.
Successfully created package 'C:\nuget\Myproject.1.0.0.0.symbols.nupkg'.
Should I just bite the bullet and write some regex to parse out the "successfully created package" lines?
By default nuget pack will output the created packages to the current directory. You can override this by specifying the OutputDirectory option. It is not clear to me from where you run the nuget command (be it from within C:\Users\me\prg\, C:\nuget\, or somewhere else), so you might already know this, but it can offer you an alternative option:
You can create yourself a temporary directory (e.g. C:\nuget\temp\), which you can specify as your OutputDirectory option. If you then in your script make sure that this directory is empty before you run nuget pack, your can simply copy *.nupkg to your fileshare (and then afterwards move it to C:\nuget\, if that is required).
Parsing the output in powershell is not too hard.
$a = nuget pack .\Exceptional.csproj -Prop Configuration=Release | Select-String nupkg
$a -Replace "^[^']'", "" -Replace "'[^']$", ""
gives
C:\Users\phelan\workspace\Exceptional\Exceptional\Weingartner.Exceptional.1.2.6011.19372.nupkg
I made a slight change to the answer provided by #bradgonesurfing as his partly worked for me.
$pack = . $nugetPath pack rest of command........ | Select-String nupkg
$pack -match "'(?<nupkg>.*)'"
$packageFile = $Matches["nupkg"]
To get it in a post build event, I would use the powershell.exe to shell out to a powershell script. I have an example here that I used to automate running editbin that can be modified for nuget: https://gist.github.com/tcartwright/cc1bd4dc98349579630c43283c5f1fe9