We’ve previously migrated our codebase from windows_x64 to linux_x64 and are now eyeing a move to linux_arm64
Our CI is building all the correct packages already.
Our previous process was to use two different steps inside the same process. One ran on our targets with the role xyx windows and selected the windows_x64 package, while the other targets had the role xyx linux and selected the linux_x64 package.
I’ve hunted around but there doesn’t seem to be any method of accessing the target host architecture from the tentacle. This would make it really easy to choose the correct package as we wouldn’t need to rely on architecture specific roles and simple use a variable in the Package step i.e. “package_#{architecture}”
I imagine an #{Octopus.Machine.Arch} variable would be super useful for us if it could output from a list of standard constants x64, x86, arm, arm64 etc
My current plan is to collect the architecture via running arch on the target and then using that as an output variable for the later package step. Seems a bit of a faff.
Is there a simpler way of doing this?
Ideally I don’t want to go back in now and create a bunch of architecture specific roles either.
I definitely think having the machine architecture available for deployments is a good idea so we’re going to add this to feature discussion for potential implementation in the future.
In the meantime, depending on the amount of machines you have it might be better to do it manually.
However, if you have a lot of machines you could run a scheduled runbook that uses logic to find the architecture then uses the API to remove old architecture roles/environments if they exist, then add the new one to the target. I would also make this run on a machine event trigger for when the machine becomes healthy so it automatically happens right away when a machine gets added to your Octopus instance. I haven’t tested this myself so please test this thoroughly before you use it in prod if you go this way. The logic seems like it should work fine, though.
Other than that, your output variable might be the best way to go.
Please let me know what you think and if you have more questions.
I’ve had some discussions internally with a couple of teams on a workaround and also if this is something we can potentially expose as a system variable in the future.
The workaround still looks to be the above solution.
Thanks @jeremy.miller
This looks like a great addition.
I think my output variable idea is a non starter because when I apply it to the Package step, while that probably works, it breaks our versioning automation as the package can’t be detected properly when creating a release.
I’ll probably go with my original Role approach and potentially enhance it with your runbook suggestion.
Thanks again for listening to me, and I appreciate your thorough responses.