0

We have a Mainline build versioned "x.0.0.r" where we publish a web service using octopus. Our branches are versioned "x.y.z.r" for specific releases. We DO NOT want to publish this web service when building from a branch.

We are using TFS: 2013 xaml build def; msbuild args: "... /p:RunOctoPack=true ..."

Short of setting /p:RunOctoPack=false or removing the OctoPack arguments from the branch build definition, is there any other way to NOT run Octopus? Perhaps in the packages.config file, to say if the version is NOT ".0.0." set "\p:RunOctoPack=false"?

We have missed removing this parameter when branching and cloning the build def and have mistakenly published the web service from the branch a few times. Would like to avoid this going forward.

Thanks,

tom

Tom
  • 162
  • 8
  • What is meant under "to NOT run Octopus". Did you mean to not run Octopack? Or to not push a package to the NuGet server? – Alex M Jan 29 '18 at 10:00
  • Yes, I was looking for a way to say do not run or include OctoPack unless version has X.0.0.y for the version. We use year for our major numbers so our Mainline builds are always 18.0.0.Rev# - we only want to run Octopack from Mainline since all released versions will not be 18.0.0. I've actually done it a different way, basically just created a simple project that clones the build def and sets the msbuilds args parameter without the OctoPack args. – Tom Jan 29 '18 at 15:11

1 Answers1

1

The deployments you describe are a bit confusing. I think you are wanting to deploy all versions tagged with version 18.x.y.z and not deploy any other version numbers.

Using Channels in Octopus would allow you to achieve this, without adding logic into your build process.

In your deployment process in Octopus, you would have a step that is deployment of your application. This is the one that you only want run when you are deploying version 18.x.

In the Channels section, add a channel and create a version rule for the channel. The package step will be the deployment step created earlier, and the version range will be something like [18.0.0,18.999.999.999)

The Version Rule Design screen gives you the ability to add sample version numbers to test your version expression.

This means that all deployments of version 18 will run the package step, and all others will skip it.

You can also get additional help via the Support channels

benPearce
  • 37,735
  • 14
  • 62
  • 96
  • Thanks Ben I will look into this. I understand the confusion but we only deploy from our Mainline to our datacenter for this particular web service. It is never deployed from a release branch. So it should always be version 18.0.0.rev for 2018 builds as it was 17.0.0.rev for 2017 builds. So we only want to deploy 18.0.0 builds. Again, the issue is forgetting to remove the /p:RunOctoPack=true msbuild cmdline argument when creating the branch and cloning the build definition. Thanks – Tom Jan 30 '18 at 18:00
  • Are the branch builds just for compilation and unit testing execution? If that is the case, maybe you might be better off having two build configurations, one for Main and one for branches. You probably need to reduce the risk of pushing a branch to production as much as possible, at the expense of maintaining two build configurations. – benPearce Jan 31 '18 at 22:53