OctopusDeploy Maven Feeds for SNAPSHOT versions

(siddharth) #1

Hi Team,
We have SNAPSHOT & RELEASE repo as maven feeds from Octopus Deploy.
We have two versions of parallel projects going on and below is versioning deploying to same group/artifactid -
I read from below that Octopus Deploy always downloads the latest SNAPSHOT version.

Question is -What will happen if Project A having major version is 1 (lower version than Project B), will Octopus Deploy download the latest version of Project B i.e. 2 major version though Project A has been triggered?
If yes, is there any way we can force Octopus Deploy to download the respective Project versions and NOT checking the latest SNAPSHOT version?I read above forcedownload?


(siddharth) #2

Forcedownload downloaded the latest version i.e. 2.0.*-SNAPSHOT. We need to find a way that it supports both versioning of parallel development workstreams for SNAPSHOTS

Please help.


(siddharth) #4

@Daniel_Fischer Hi Daniel, hope you’re doing good. Could you please let us know and update us soon as we are blocked with doing developments of two parallel projects with two different major version stream?The project running with 1.0.-SNAPSHOT stream is getting impacted as though the release is created of 1.0.-SNAPSHOT, Octopus Deploy is deploying the latest higher major version i.e. 2.0.*-SNAPSHOT?

(Daniel Fischer) #5

Hi Siddharth,

Thanks for getting in touch here! I’m sorry for the delay in getting back to you on this. I am thinking that you may be able to handle this by using Channels.

Channels let you define version rules and tell Octopus which version of a package should be used when a release is created for the specific Channel.

Our documentation on Channels has a lot of details on how you can take advantage of Channels in your deployment.

As an example, If you had the following package versions in Octopus:


You could create a version rule in Project A such as:


This version rule would select the latest package which starts with 1.0 through to 1.9. See below for an example:

If you created these version rules for each of your projects, you can control which major version of the package was selected by default at release creation time.

The following documentation page from Maven has details on the available version rules you can use and what they do.

You can also have multiple Channels on each project so you can have different version rules for different scenarios.

Does this sound like what you are after?

If I have missed anything here, or if you have any questions at all, please let me know.

Best regards,

(siddharth) #6

Hi Daniel,
Thank you so much. I will try this.
My Octopus Deploy Project is common for both the projects having three ENV’s in life cycle.
Octopus Project 1–>Process 1–>1.0.1-SNAPSHOT --> ENV 1
Octopus Project 1 —>Process 1–> 2.0.1-SNAPSHOT —> ENV 2

I was seeing the CHANNEL there is no option to set the CHANNEL to ENV mapping I think.
So I will break the process into three for the same Project…and restrict the ENV for each process

Octopus Project 1–>Process 1–>CHANNEL 1 -->1.0.1-SNAPSHOT --> ENV 1
Octopus Project 1 —>Process 2–>CHANNEL 2 --> 2.0.1-SNAPSHOT —> ENV 2

Is that fine?


(Daniel Fischer) #7

Hi Siddharth,

Thanks for getting back! Generally Octopus considers that each release is read only and that the package version for any given step used between each environment will be the same that you create the release with.

We are fairly opinionated about how a release “Should” look, which follows something like a Dev -> Test -> Prod style Lifecycle, where the same exact data is used at each stage so there are no unexpected surprises when your project reaches your production environment.

However, Octopus is also fairly open to be used however you need and is perfectly capable of doing what you need here. If you require a separate package version for each subsequent environment, then you can do as you have suggested.

    • Set your initial package step to be restricted to ENV 1.
    • Create an additional package step in your project.
    • Restrict the step to ENV 2.
    • Set the Channel version rules specifically for that step to use 2.0.1-SNAPSHOT.

The new step will only execute when the release is deploying to ENV 2 and it will use your desired 2.0.1-SNAPSHOT version.

Let me know if this helps, or if you have any further questions here. :slight_smile:

Best regards,

(siddharth) #8

Thanks @Daniel_Fischer.Could you please advise-
1)If this CHANNEL rule I have to define for each SNAPSHOT project or can be put in the global central level so that the same channel can be used instead of creating each for each project?
2)Initially I didnt pass --channel=Rule in the octo command to create-release and it had failed, why this is required to pass when I have selected that in the Deployment process.Err below-
Creating release…

Release 1.0.84-giuifunctions-SNAPSHOT created successfully!

There was a problem with your request.

  • There are no steps to run when deploying releases of GIUI-FUNCTIONS in the Default channel to the CIT environment. This can happen if your deployment process is empty, or review the filters applied to the steps in your deployment process.

Once you have corrected these problems you can try again.

If the problem is related to a variable you will need to update the variables for this release or recreate the release for the changes to take effect.

If the problem is related to the deployment process you will need to create a new release for the changes to take effect.

Error from Octopus Server (HTTP 400 BadRequest)

Exit code: -7

3)For RELEASE maven versions, does this require or picking the latest versions feature is only for SNAPSHOT versions ?


(siddharth) #9
  1. And aslo for one ENV called ST we should have the flexibility to deploy both versions of the code as that is shared ENV.Please advise how to handle that?
    Is that while passing parameter to deploy-release , i will pass --channel=$Rule and let the Rule be passed as parameter dynamically?


(siddharth) #10

Hi @Daniel -Could you please advise soon on my queries?