Having two projects A and B, how can I reference on each tentacle an executable from the installed package of the latest successful release of project A, from a step in project B running on the same tentacle?
Hi Nick
Thanks for getting in touch!
If I read it correctly, project B depends on a package from project A, in this case, could you add an extra step in project B to deploy the package the it needs (e.g. the executable from project A), by doing that you could get the path of where the package is installed by using a system variable Octopus.Action[Your step name].Output.Package.InstallationDirectoryPath.
Octopus provides some other variables that expose different path, you could get more information about them from this link https://octopus.com/docs/deployment-process/variables/system-variables
Alternatively you could get project A to output the path of the package to an external file that project B can read.
I hope this helps!
Let me know how you go.
Regards
Eddy
Thanks Eddy, I understand the two options you give, but the one I’m seeking is not given.
In my mind there would be four options, including your suggestions:
- Package B process has step to deploy package A, and allows capture and use of Octopus.Action[Deploy Package A].Output.Package.InstallationDirectoryPath, but only for the duration/within the scope of the rest of that Package B process.
- Package A process outputs the path of the A package to an external file which Package B can later read as per your suggestion.
- Package A process updates the value of an Octopus project(?) variable with the path of the A package, which can then later be read/used by Package B
- A release for Package A is successfully deployed. Later, Package B has a step which accesses through intrinsic Octopus variables the package path of the latest successfully deployed Package B, per target.
It’s option 4 which seems the easiest and most obvious. But is this possible? Does Octopus keep track of the paths of the latest successful deployment of every package? I would think surely it must do, because it shows them on the dashboard and project overviews.
Hi Nick
There are some pros and cons for each option
-
Option 1
Pros: Use all existing Octopus functionalities and no external dependencies
Cons: This might not suit your scenario as two projects might deploy at different time -
Option 2
Props: Two projects can deploy at different time, better suit your business case
Cons: Introduce external dependencies which could be fragile -
Option 3, 4
Pros: Might suit what you need
Cons: External dependencies, not easy to setup
I would suggest option 1 if you could, otherwise here is the sample code for option 3,4, this sample is assuming Project A sets a output variable in one of its step named Set out var, the output variable name is TestResult, and you would like to get it out from your Project B
Do the following setup in order to get the sample code running
Firstly, go to Library , External Feeds and add a new feed for the public Nuget server, with a URL of https://api.nuget.org/v3/index.json . Feel free to enable the extended API.
After that, create a script step in your project, and in the Referenced Packages section add a reference to the Octopus.Client package in the new external feed you created.
Finally, in the Inline Source Code section, select C# and provide your script and put in the follow scripts. You will need to set the server address as well as the API key, you can find more information about how to generate API key from this link https://octopus.com/docs/api-and-integration/api/how-to-create-an-api-key
#r "Octopus.Client\lib\net45\Octopus.Client.dll"
using Octopus.Client;
var repository = new OctopusRepository(new OctopusServerEndpoint("YOUR_SERVER_ADDRESS", "API_KEY"));
var deployment = repository.Deployments.Get("Deployments-43"); // The latest successfully deployed deployment ID from project A
var variableSet = repository.VariableSets.Get(deployment.ManifestVariableSetId);
var myVar = variableSet.Variables.Single(v => v.Name == "Octopus.Action[Set output var].Output.TestResult");
Console.Write(myVar.Name);
Console.Write(myVar.Value);
I hope this helps!
Let me know how you go.
Regards
Eddy
Hi Eddy,
I don’t see how the proposed option using the an output variable and the API can return the correct $OctopusParameters[‘Octopus.Action[DeployStepName].Output.Package.InstallationDirectoryPath’] for every Target. Remember, it can differ per Target.
For now, I have thought of another way (option 5) which is similar to option 2, and which for Project A to have a step that on each target sets the value of a Windows System Environment Variable (e.g. %PathToPackage%) to the value of $OctopusParameters[‘Octopus.Action[DeployStepName].Output.Package.InstallationDirectoryPath’]
The pro to this method is that it will be correct for/on each target, and can be easily used with simple %%-syntax.
One con to this method is that it misses any logic for “highest successful release by version number”, i.e. a redeployment of an older version would set itself in that Environment Variable.
I must say, I’m slightly astonished that Octopus does not allow through simple Octopus variables or through API the resolving of “The path to the installation directory of the highest successfully deployed version of any specific Project”. It seems to me the information is there.
Hi Nick
I should have made the sample a bit more explicit, output variables can handle value per deployment target very well.
For example Octopus automatically capture an output variable with the machine scope, you can access them in this format Octopus.Action[StepA].Output[Web01].TestResult where Web01 is the deployment target, and also Octopus.Action[StepA].Output.TestResult with scope Deployment Target: Web01.
You can find more output variables for deployment target from this link https://octopus.com/docs/deployment-process/variables/output-variables#Outputvariables-Outputfrommultiplemachines
I hope this helps!
Regards
Eddy
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.