I just discovered Squirrel (it’s still in very early stage of development) which allows to create a NuGet package of an application. Then it bootstraps the NuGet packages and installs the software just like ClickOnce (but then better of course). For this process, it works like this:
1) Build software 2) Create NuGet package with application files 3) Run Squirrel.exe => creates the bootstrapper + update packages + delta packages.
As you can probably imagine, you can only create a delta package when you have access to the previous packages. For example:
Build #1 => 1.0.0 creates the following files:
MyPackage-1.0.0-full.nupkg
RELEASES
Setup.exe
Now I build #2 => 1.1.0 which should create the following files:
MyPackage-1.0.0-full.nupkg
MyPackage-1.1.0-delta.nupkg
MyPackage-1.1.0-full.nupkg
RELEASES
Setup.exe
Is it possible to create some sort of “workspace” for a project that can be used in scopes of a build? I would only need the files temporarily when calling “Squirrel.exe” to create the delta packages. I hope to use the Workspace Rules for that, but it’s all relative to the workspace and I don’t think I can get outside of it, right?
As a last resort, I might check in the files into repository, but I would prefer to prevent that (because artifacts shouldn’t be pushed into a repository).
Hi Geert, it’s great to hear new ideas and projects that people are using, thank you very much for sharing. What you mentioned is possible under the current Continua build. We are currently investigating how this kind of use case can be made more efficient (items on our Project backlog related to build dependencies).
We have discussed internally, and believe the below workflow would solve this use case:
2) Create a Property Collector (more info here) for Squirrel (this can be used in the agent requirements section of a stage)
3) Ensure that the Configuration in question is set to only allow a single build at a time (create a condition on the configuration where $Configuration.RunningBuilds$ <1 and $Configuration.QueuedBuilds$ < 1). This ensures a level of atomicity required for step 5
4) Within a stage create an execute program action which gives the respective command line arguments to Squirrel (including the network location of the dependencies). One example could be to have a network share \SERVERNAME\test\latestBuild which contains the most recent nupkg file(s). Depending on your requirements you may need to copy this folder to the agent workspace (in this case please ensure you have the respective workspace rules enabling the files to be copied back to the server, and thus portable between stages).
5) Create an additional stage at the end of the build which checks for build success (eg unit tests, compiler errors, or a configuration variable for the success or failure of the Squirrel process) and runs a copy action of the required .nupkg files to the network location (eg \SERVERNAME\test\latestBuild, first cleaning the folder or archiving its contents as required).
6) Add the resultant nupkg files as artifacts (might also be worth adding the dependant nupkg files as artifact’s so you have greater visibility into what versions of the dependencies went into a given build version).
A few things to note: - The Continua Agent service account will need full network security permissions to the network share - You are decoupling your dependencies from your version control (sometimes this can be a bad idea, step 6 should help with this)