Skip to content

Commit ebed663

Browse files
committed
Merge pull request #468 from jamescrowley/patch-1
Fix namespaces of imports in OctoTools example
2 parents 10f0ca6 + aba1b5d commit ebed663

File tree

1 file changed

+3
-3
lines changed

1 file changed

+3
-3
lines changed

help/octopusdeploy.md

+3-3
Original file line numberDiff line numberDiff line change
@@ -30,7 +30,7 @@ Octopus Deploy relies on the concept of a **release**, which should be an immuta
3030

3131
So once you have created a project you are able to create a push a release into Octopus Deploy. This can be done through the Octopus UI, command line tool, or in our case - from a FAKE script.
3232

33-
open OctoTools
33+
open Fake.OctoTools
3434

3535
Target "Release" (fun _ ->
3636
let release = { releaseOptions with Project = "Order Processor" }
@@ -52,7 +52,7 @@ You can automatically deploy a release when you create it, but using the optiona
5252

5353
This is often a good idea when you want your FAKE build script to continue on to a second set of perhaps slower, unit tests that exercise behaviours in a more complete and perhaps integrated environment.
5454

55-
open OctoTools
55+
open Fake.OctoTools
5656

5757
Target "ReleaseAndDeploy" (fun _ ->
5858
let release = { releaseOptions with Project = "Order Processor" }
@@ -73,7 +73,7 @@ In this instance we've used the default `deployOptions` and modified the environ
7373

7474
Finally when you are absolutely happy that your release is good to go the next stage (be that some manual or exploratory testing, or perhaps a staging environment). We can use a `DeployRelease` command to promote an existing release to the next environment:
7575

76-
open OctoTools
76+
open Fake.OctoTools
7777

7878
Target "PromoteRelease" (fun _ ->
7979
let promote = { deployOptions with

0 commit comments

Comments
 (0)