I am trying to automate the build + deployment of a website. I have followed the blog post, but get an error. I do a few things differently:
1) I build (I set octopack to true, but do not specify deployment urls because I want to do this separately)
2) In the deploy stage (that is not executed in CI builds), I have added event handlers (before and after) as described in the blog post. Inside the deploy stage I push the nuget package to the octopus deploy server.
Then I get this error:
Executing event handlers for ‘On Before Stage Start’ build event
Executing handler ‘Create Octo release’ for build event 'On Before Stage Start’
An error occurred while retrieving Octopus Deploy project details for the project ‘MyProjectName’. The response from the server was:
Build failed while executing event handlers for ‘On Before Stage Start’ build event
I would love to see the error message that was returned 
It looks it was caused by a bad ssl certificate. I have now used valid (wildcard) ssl certificates and I get this error message:
The response from the server was: { “ErrorMessage”: “The resource you requested was not found.” }
And I need to learn to read: the url in the blog post to the actual api is different from the package url. I have now created 2 application-wide variables so this won’t happen again.
I did find a bug though: at first I had a single event handler with 2 actions (create and deploy). Then I thought I wanted them separated so unchecked the “deploy” part of the first action, but it will still throw errors about missing version numbers in the “deploy” step (but I only have “create” checked).
Also, when I use a variable (of the configuration), it looks like it is not working.
%GitVersion_ClassicVersion% fails with this error message:
Could not resolve package versions for the following deployment steps:
Deploy. Please supply these in the Package Versions field or provide a Default Package Version
When I use this $Build.Version$, I get this one:
An error occurred while retrieving Octopus Deploy deployment process with the id ‘deploymentprocess-projects-1’: ‘0.1.0+38’ is not a valid version string. Parameter name: version
The %GitVersion_ClassicVersion% is set in a stage before. Is it possible that the event handlers don’t re-evaluate the variable value? When I hard-code the version of 0.1.0, it works fine.
Posted By Geert van Horrik on 03 Oct 2014 02:51 PM
I did find a bug though: at first I had a single event handler with 2 actions (create and deploy). Then I thought I wanted them separated so unchecked the "deploy" part of the first action, but it will still throw errors about missing version numbers in the "deploy" step (but I only have "create" checked).
I'm not able to reproduce this here, but will get Dave to look at it on Tuesday (Monday is a holiday here).
Posted By Geert van Horrik on 03 Oct 2014 03:11 PM
Also, when I use a variable (of the configuration), it looks like it is not working.
%GitVersion_ClassicVersion% fails with this error message:
Could not resolve package versions for the following deployment steps:
Deploy. Please supply these in the Package Versions field or provide a Default Package Version
When I use this $Build.Version$, I get this one:
An error occurred while retrieving Octopus Deploy deployment process with the id 'deploymentprocess-projects-1': '0.1.0+38' is not a valid version string. Parameter name: version
The %GitVersion_ClassicVersion% is set in a stage before. Is it possible that the event handlers don't re-evaluate the variable value? When I hard-code the version of 0.1.0, it works fine.
Looks like two issues here. Looking at the code, I think it's using the wrong variable namespace (config instead of build) when evaluating expressions. The second is SemanticVersion throwing when parsing a value we get back from Octopus. I'm in the process of setting up the project on my dev machine to take a look at this.
Hi Geert
As I suspected, the wrong variable namespace was being used, I’ll get a build uploaded with a fix for this shortly. The other issue I’m still trying to reproduce. The package version does need to be parsable by SemanticVersion - for example :
this will parse : 1.0.2.3-alpha-two
this will not parse : alpha-two-1.0.2.3
So I guess the first thing to check is what you are specifying as the package version.
I’m not sure why we are requiring that they are parsable by SemanticVersion - need to discuss this with Dave next week. This build includes the fix for the variable issue :
http://downloads.finalbuilder.com/downloads/continua/1.5/ContinuaCI.Server.Setup_x64_1.5.0.325.exe
http://downloads.finalbuilder.com/downloads/continua/1.5/ContinuaCI.Agent.Setup_x64_1.5.0.325.exe
http://downloads.finalbuilder.com/downloads/continua/1.5/ContinuaCI.Server.Setup_1.5.0.325.exe
http://downloads.finalbuilder.com/downloads/continua/1.5/ContinuaCI.Agent.Setup_1.5.0.325.exe
Awesome, thanks for all the replies. I will use numbers to respond:
1) I think this is my fault. The tab is called “deploy”, but the stage was also called “deploy” so there might be confusion on my side. When I enabled the checkbox, it showed the previous values. I think that’s for convenience, so this has very low prio (probably not even an issue).
2) The semantic version thing is “ok”. It’s a nuget thing where you cannot use SemVer (they will support in v3), so I will use ClassicVersion (1.2.3.4) instead of SemVer (1.2.3+4). Don’t need to discuss, as soon as Octopus Deploy will use NuGet v3, it will be supported.
Thanks for releasing a new version. I will test immediately.
Did you change something in the evaluation of $Workspace$ in the NuGet push action? I now get this error:
NuGet Push [$Workspace$\Artifacts%OctopusDeployPackageName%] 9:06 AM9:06 AM0 millisecondsFailure
Parameters
Working Directory: C:\CI_WS\Ws\4060$Workspace$\Artifacts
Executable: C:\Tools\NuGet\NuGet.exe
Arguments: push C:\CI_WS\Ws\4060$Workspace$\Artifacts%OctopusDeployPackageName% ****************************** -Timeout 300 -NonInteractive
Environment Variables
The working directory does not exist : C:\CI_WS\Ws\4060$Workspace$\Artifacts
When I use $Workspace$\Artifacts%OctopusDeployPackageName% as package name. I can work around it but it would be a massive breaking change (al my 40 projects use $Workspace$ when pushing NuGet packages).
And it looks like the % variables are no longer being expanded (but only in the Package field, the Source Server / API key are working as they should).
The only change I made was the variable namespace used when expanding expressions in build event handlers (which happens on the server). Actions run on the agent. I had a look at the code for the push action and it does expand variables. Will test again tomorrow.
Thanks. Note that I didn’t have the latest version before I installed the nightly build. It might be introduced by the latest stable build, not sure. I will double check now.
I did some more research, when I use the variable in the stage syncing, I get this error:
Started syncing files from the agent to the server.
An error occurred while syncing files from the server to the agent. Details: Exception: NullReferenceException Message: Object reference not set to an instance of an object. Stack Trace: at Continua.Shared.Utils.FileMatcher.b__1(String x) at System.Linq.Enumerable.WhereListIterator1.MoveNext() at Continua.Shared.Utils.FileMatcher.ParsePatterns(IEnumerable1 patterns) at Continua.Shared.Utils.FileMatcher.GetMatches(IEnumerable1 patterns) at Continua.Modules.Builds.Agent.FileSync.UNCTransport.Copy(String destination, String pattern, IEnumerable1 excludes, String basePath, RuleOperator op, Int32& filesCounted) at Continua.Modules.Builds.Agent.FileSync.UNCTransport.ExecuteAgentToServerRule(String source, IEnumerable1 excludeRules, WorkspaceRuleDTO rule) at Continua.Modules.Builds.Agent.FileSync.UNCTransport.CopyFilesFromAgentToServer(String source, IEnumerable1 rules) at Continua.Modules.Builds.Agent.AgentBuildHelper.SyncWorkspaceToServer(TransportContextDTO context, IEnumerable1 rules, AgentWorkspaceSyncContext workspaceCtx) at Continua.Modules.Builds.Agent.AgentBuildRunner.OnSyncingWorkspace(Transition1 inState) .
Below is the variable definition:
OctopusDeployPackageName%ProjectName%.Website.%GitVersion_ClassisVersion%.nupkgExpression
Is something wrong with this definition?
What is the variable type and how are you using it on the stage (what is the pattern?).
Just noticed you already included the variable info, I shouldn’t post pre-coffee!
The exception is occuring when processing the any patterns for includes/excludes. I need to see your patterns to figure out what is going on.
Ok, I think I’m narrowing in on the problem. Do you have a variable named ProjectName ? I was in the process of replicating your setup, and forgot to define that variable, and then started seeing similar errors in the nuget push action to what you reported.
The issue appears to be a case where the string expansion code is not throwing an exception when it fails to parse an expression and instead just returns the original expression. The function takes a bool value (default false) to determine whether to throw or not, but I cannot see a situation where it wouldn’t want to throw (a bad expression is useless). I need to discuss this with the team as flipping the logic might break something else (I’m slwoly working my way through the code to find cases where that might happen).
Hi Geert
Please try this build (you will need to update your agent).
http://downloads.finalbuilder.com/downloads/continua/1.5/ContinuaCI.Server.Setup_x64_1.5.0.327.exe
http://downloads.finalbuilder.com/downloads/continua/1.5/ContinuaCI.Agent.Setup_x64_1.5.0.327.exe
http://downloads.finalbuilder.com/downloads/continua/1.5/ContinuaCI.Server.Setup_1.5.0.327.exe
http://downloads.finalbuilder.com/downloads/continua/1.5/ContinuaCI.Agent.Setup_1.5.0.327.exe
This build fixes the issue I found with the nuget push action not reporting errors when it can’t expand the package.
You will need to update your agents.
Action ‘NuGet Build [Artifacts%OctopusDeployPackageName%]’ has failed due to an error.
Could not expand query ‘Artifacts%OctopusDeployPackageName%’. The expression ‘MyCompany.Management.Portal.Website.%GitVersion_ClassisVersion%.nupkg’ contains errors: Unknown Variable : GitVersion_ClassisVersion
How could I overlook that?! It’s a ClassicVersion. This addition is great because now we no longer have to such errors.
All seems to work out now, thanks! There is 1 minor issue / thing that might behave different: I have 2 handlers:
1) Create release in Octo (this is the output):
Executing event handlers for ‘On Before Stage Start’ build event
Executing handler ‘Create Octo release’ for build event ‘On Before Stage Start’
Release version ‘0.1.0.38’ already exists - skipping release creation
Finished executing event handlers for ‘On Before Stage Start’ build event
2) Deploy release in Octo:
Executing event handlers for ‘On Stage Completed’ build event
Executing handler ‘Create Octo release’ for build event ‘On Stage Completed’
No release has been created by this event handler to deploy.
Build failed while executing event handlers for ‘On Stage Completed’ build event
I think that if the setting “Release created by this event handler” is used in the Deploy step, it should use the release even when it already exists. I will work around this by specifying the manual release version.
I am very happy with the results so far, I can release a website without a hassle now, thanks for the great support.