I'm have command line tool built as a NuGet by TeamCity.
My problem is that I would like to use the tool in a build step within the same TeamCity server and the execute the command line tool as part of the step.
The easiest way would be to just compile the command line tool and create an artifact without creating a NuGet and then take an artifact dependency in the other build process and execute the command.
But I would like to know if it's possible to do the same with a NuGet package so I can reuse the tool for other purposes?
Update
After some more testing with TeamCity I think the main issue is that the "NuGet Installer" runner requires a solution file. I can do what I want with a powershell task:
# install the latest package
%teamcity.agent.tools.dir%\NuGet.CommandLine.2.7.1.nupkg\tools\NuGet.exe install octospike-migrator -o tools -excludeversion -source %teamcity.nuget.feed.server%
# run the command line tool
.\tools\octospike-migrator\lib\Octospike.Command.exe
The build step above is working a intended but I have the feeling that the default runner "Nuget Installer" should be able to handle this?
I'm running TC7 so it might be working in TC8
Assuming the package is referenced in your solution and you have enable missing package restore enabled, the package will be downloaded and unpacked into your solution. The executable will go into a known location (whatever directory you've specified for the package). You should then be able to access the executable as you would any other resource.
If you need flexibility in regards to where and how the resources are unpacked (e.g., if they need to go in a directory outside of the project), you can build this as a Tools package in NuGet.
In TeamCity, the complexity will be reduced if you break this process into separate tasks.
Related
I need a NuGet (example xunit.runner.console) to run UT from command line.
Right now in one of project I have added xunit.runner.console as dependency so it is downloaded, path is known and I can use it in my build script.
This Project was removed and build-script is broken now. I will need to add it to another project, but the same situation can occur again (or other reasons).
I there a way to download this package but don't link it with concrete project?
You can install the nuget cli and then get the package needed using the build script. So, to answer your question, you can just use it in the build script and fetch the package before starting to build your project.
I am trying to run gradlew on offline machine. It starts from message
Downloading https://services.gradle.org/distributions/gradle-2.10-all.zip
and then fails with exception.
What it wants and how to satisfy it?
Option 1. If you have possibility go online temporary
Command gradlew means you are trying to use Gradle Wrapper. It is a tool for automated downloading of Gradle distribution.
In order to download Gradle Wrapper you have to execute gradlew command with a proper network connection at least once.
Make sure you have correct network and proxy settings.
./gradlew build
Only after that you can build a project offline. Example:
./gradlew build --offline
Option 2. Download distribution by hand
Or, alternatively, you could download distribution from official site. Then extract it, add gradle to PATH variable, and run:
gradle build --offline
I'm setting up a build on Teamcity that will build a XCode project, then create a release in Octopus and using Powershell copy the files into a server. However, I'm having an issue, while both steps (Teamcity and Octopus) work independently, currently Teamcity is telling me that my build agent does not complies with the requirement 'OctopusDeploy: Release'.
I've downloaded the plugin that is here, and have managed to put the zip file on the runner directory, and while Octopus restarted and seems to have installed it, it still doesn't show as one of the available Build runners.
Apparently you can't do this, or that's what it seems like. Installing the plugin on a fresh install of Teamcity ignored the Mac build agent, which means it's not compatible.
This makes sense because Octopus uses an exe wrapper so this could be the reason. If anybody finds something else, feel free to contribute.
New Go programmers often don't know or get confused what the fundamental go build command does.
What do exactly the go build and go install commands build and where do they put the result/output?
What the go command does depends on whether we run it for a "normal" package or for the special "main" package.
For packages
go build builds your package then discards the results.
go install builds then installs the package in your $GOPATH/pkg directory.
For commands (package main)
go build builds the command and leaves the result in the current working directory.
go install builds the command in a temporary directory then moves it to $GOPATH/bin.
What to pass to go build?
You may pass packages to go build, packages you want to build. You may also pass a list of .go files from a single directory, which is then treated as the list of source files specifying a single package.
If no packages (import paths) are provided, the build is applied on the current directory.
An import path may contain one or more "..." wildcards (in which case it is a pattern). ... can match any string, e.g. net/... matches the net package and packages being in any of its subfolders. The command
go build ./...
often used to build the package in the current folder and all packages recursing down. This command issued in a project root builds the complete project.
For more about specifying packages, run go help packages.
Regarding modules
Preliminary support for Go modules was introduced in Go 1.11, and modules became default starting with Go 1.13. When the go tool is run from a folder which contains a go.mod file (or one of the parents of the current folder), the go tool runs in module-aware mode (the legacy mode is called GOPATH mode).
In module-aware mode, GOPATH no longer defines the meaning of imports
during a build, but it still stores downloaded dependencies (in GOPATH/pkg/mod)
and installed commands (in GOPATH/bin, unless GOBIN is set).
When building modules, what is built is specified by the build list. The build list initially contains only the main module (the module containing the directory where the go command is run), and the dependencies of the main module are added to the build list, recursively (dependencies of dependencies are also added).
For more info, run go help modules.
Basically you can use go build as a check that the packages can be built (along with their dependencies) while go install also (permanently) installs the results in the proper folders of your $GOPATH.
go build will silently terminate if everything is OK, and will give you error messages if the packages cannot be built/compiled.
Whenever the go tool installs a package or binary, it also installs whatever dependencies it has, so running go install will also install packages your program depends on (publicly available, "go gettable" packages), automatically.
For a start, read the official How to Write Go Code page.
More information about the go tool: Command go
You can also get more help by running the following command:
go help build
It is also worth noting that starting with Go 1.5 go install also removes executables created by go build (source):
If 'go install' (with no arguments, meaning the current directory)
succeeds, remove the executable written by 'go build', if present. This avoids leaving a stale binary behind...
To complete the list, go run compiles your application into a temporary folder, and starts that executable binary. When the app exits, it properly cleans up the temporary files.
Question inspired by Dave Cheney's What does go build build?
For package:
go build: builds your package then discards the results
That won't be true after Go 1.10 (Q1 2018), thank to CL 68116 and CL 75473. See this thread, that I reference here.
What do exactly the go build and go install commands build
Whenever the go tool installs a package or binary, it also installs whatever dependencies it has, so running go install will also install packages your program depends on (publicly available, "go gettable" packages), automatically.
Actually... go install will change also with Go 1.10, in addition of the new cache:
The "go install" command no longer installs dependencies of the named packages (CL 75850).
If you run "go install foo", the only thing installed is foo.
Before, it varied. If dependencies were out-of-date, "go install" also installed any dependencies.
The implicit installation of dependencies during "go install" caused a lot of confusion and headaches for users, but it was previously necessary to enable incremental builds.
Not anymore.
We think that the new "install what I said" semantics will be much more understandable, especially since it's clear from bug reports that many users already expected them.
To force installation of dependencies during "go install", use the new "go install -i", by analogy with "go build -i" and "go test -i".
The fact that "go install" used to install any rebuilt dependencies caused confusion most often in conjunction with -a, which means "force rebuild of all dependencies".
Now, "go install -a myprog" will force a complete rebuild of all dependencies of myprog, as well as myprog itself, but only myprog will get installed. (All the rebuilt dependencies will still be saved in the build cache, of course.)
Making this case work more understandably is especially important in conjunction with the new content-based staleness analysis, because it sees good reasons to rebuild dependencies more often than before, which would have increased the amount of "why did my dependencies get installed" confusion.
For example, if you run "go install -gcflags=-N myprog", that installs a myprog built with no compiler optimizations, but it no longer also reinstalls the packages myprog uses from the standard library without compiler optimizations.
When we download git project and click build button in VS, it restores nuget packages and then compile. always cool.
Just like that, I'd like to install Redis locally before compile because my project unit test job requires Redis.
I found Redis-64 in nuget but I don't know why it does not install properly. It displays "Redis-64 is already installed" but it's not.
There is Chocolately nuget package and Redis for chocolatey. It looks promising to utilize them.
To achieve my goal, it would be required to (1) check installation of chocolately first, and then (2) download redis-64, and then (3) execute redis-server.exe before compile process (could be placed at the Pre-build event command in .csproj property).
I want to know how to check Redis chocolatey installation and rest of other steps in VS. Would you please teach me how to achieve to do that?
I could be way off the mark here, but the redis package that you are referring to, i.e. from NuGet should only include the assemblies that you could then consume within your application. If you actually want to have the Redis application installed, you would want to install the Redis application from Chocolatey.org, which you can find here.
In terms of getting Chocolatey etc installed as part of your build process, you might want to take a look at the build script for ChocolateGUI. As part of it's build, which is executed on AppVeyor, it checks for Chocolatey, and if it isn't there, installs it, and all required applications.
For what you want, I think you need to include:
choco install redis
Within your build script, and this will give you the redis-server.exe that you are looking for.
I installed the redis-64 NuGet package and it just worked for me. It is an unusual package in that it doesn't associate itself with any Visual Studio project, but rather it is referenced from a solution-level packages.config.
To use the Redis server in my integration test, I start the server with this code:
Process.Start(new ProcessStartInfo(Path.Combine(Directory.GetDirectories(#"..\..\..\packages", "Redis-64.*").Single(), "redis-server.exe"), "--bind 127.0.0.1") {
WindowStyle = ProcessWindowStyle.Hidden
});