Thanks for reaching out! Octo.exe push needs you to
literally tell him exactly which package file you want to push.
There's no way for it to figure out you want to push the latest
The way we recommend this to be used in a build process goes
1) Build your app from
2) Use Octo.exe pack with the
--version parameter to tell the command exactly which
version number you want to give to your package. Using Dates and
Assembly info is usually not recomended here. Instead we recommend
you to use a variable from your build that references the build
number, so you end up with something like 1.0.0 which
is usually more readable than 2017.1.10.12012. In TFS
for example that variable would be
$(Build.buildnumber), and in TeamCity is
3) Use that same build number variable to the build the full
name of the package you want to push using Octo.exe
this might not work with the Habitat Sitecore version 8.2 as the
build/deploy is done entirely by gulp, but i had to split this between
Jenkins and Octopus in order to build and deploy (this is the proof of
concept i have to achieve).
My build is using jenkins and gulp to create the package, powershell to
take the sitecore items from the code and inserted it in the Unicorn folder
in order to be serialized by Unicorn later in the deploy process.
Octo.exe comes here as the step where the zip is already done by octo.exe
with "octo pack --package".
The version you said in AssemblyFile.cs 1.0.0 might change in the future,
let's say when a developer makes a local build with Visual Studio and
increments the third number, thus becoming 1.0.1.$BUILD_NUMBER.
How can i tell octo.exe about the 1 in the third place that it has changed?
Can i use something else to push (publish) the package in Octopus? I am
opened to alternatives. Anything that works, i am happy with it.