Git Shortcommit ID to be available for octopus deployment

I am building a docker image in Gitlab. My Docker Image will have a tag equivalent to ShortCommit ID.

Gitlab will create the release in Octopus with the Short Commit ID Appended to it. I am able to test this part successfully using “octo create-release”.

However, I want this shortcommit id to be available for Octopus during the deployment, so that an image which is tagged with the “shortcommit id” can be pulled by octopus. How can this variable be passed during the deployment in octopus?

Hey @manjunatha.karekal , thanks for reaching out!

I want to ask a few questions to ensure I understand your use case.

You’re adding the short commit of a given commit to the tag for the image when it’s being pushed to your container registry, correct?

So, for instance, if you were building MyApp, and the last commit hash was 1e872b59013425b7c404a91d16119e8452b983f2, you would build the image and tag it to upload with something like MyRegistry/MyApp:1e872b5?

If you wouldn’t mind sharing, I’d love to see your tags and how the version is being selected when you create the release in Octopus. Knowing the format as it exists today will help me find the right resources for you to get what you need!


Hi Cory,
Thanks for your response.

Yes, you are right. The docker image in the Gitlab Container Registry will be stored with the tag id equivalent to the “Short Commit ID”.

Below is the pipeline flow:
In my case, the ShortCommitId is 471314468 . Gitlab stores this short commit ID in system variable called “CI_COMMIT_SHORT_SHA”

i) Gitlab pipeline is creating an image and storing the same in the Gitlab Container registry with the tag equals to the “ShortCommitID”. for ex. application_name:0471314468
ii) Gitlab will create the release in Octopus. Release name will also have the same shortcommit id appended. For. ex. : v3.0.0.471314468 .I am able to append the short commit id to octopus release by passing the $CI_COMMIT_SHORT_SHA variable from Gitlab while creating the octopus release.
iii) Now I want this short commit ID to be available while doing the deployment as well. For example, the deployment step must be able to pull the docker image created in step i) (application_name:0471314468). In order to achieve this, I would like to dynamically store the value of CI_COMMIT_SHORT_SHA gitlab variable in octopus.

How can this be achieved in octopus?

Thanks for confirming!

I think there are a couple of options available that may help you here.

When deploying containers, Octopus treats the image tag as the version for the package. For example, when I have a process to deploy the octopusdeploy/tentacle container, I get the following tags as the version selector:

Because Octopus treats those tags as the version, that means you can access them through the built-in system variables. For example, when I deployed version 6.2.59 of the Tentacle to my local machine using the Run a Docker Container step, all of the following variables are available to identify the deployed package:

If that’s not sufficient (or if you need to be able to access it another way), you could also look at adding a prompted variable to your project. You could set a variable like #{Project.GitLab.ShortCommitHash} and then pass the value for the prompted variable as a part of the create-release CLI command.

Hopefully one of those provides a way to accomplish the process you’re looking for! If you have any questions or run into other issues, don’t hesitate to reach out, we’re happy to help!


Thanks cory for your response.
Can you please let me know how did you setup the deployment process, so that you are getting the tags in the drop down?


Sure thing - that drop down is available when using the built-in Run a Docker Container step:

Selecting the package from a Docker registry feed should allow you to see the same version drop down from my initial post!

Let me know if you run into any issues, happy to help!


I have tried using prompted variable. However, it seems prompted variable works with create-release command, only with “–deploy-to” flag is used.
Can you please confirm? I would like to prevent the use of “–deploy-to” parameter in order to prevent an automated deployment.
Is there any way where I can use the prompted variable in “octo create-release” command without using “–deploy-to” flag? The prompted variable should be available to use during the deployments.

Hey @manjunatha.karekal , my apologies! Prompted variables are able to be set per deployment, so they can be tied to a specific deployment.

The best case scenario for your use case is using the package version of the container. That will ensure that you’re always getting the value of the container currently being deployed. You could use a project variable to hold this information, but as we’ve already encountered, there are challenges with that approach as well. For example, even if you used a project variable to hold the value, and created a release so the variable was tied to a specific release snapshot, you’d neve be able to go in and update that variable snapshot, because it would change the value of that variable.

Is there a reason why accessing the tag as part of the container selection for the deployment isn’t working for your intended use case?

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.