Hi guys, I have an issue with Octopus not being able to parse the name of a package in the Maven feed.
We have some Scala code artifacts there and we add Scala version at the end of the package name (e.g com.mycompany:some-package_2.11). When I try to use test action from the feed and search for this package, I find nothing. When I create a release with this package id, it shows error inside the release:
Failed to retrieve notes: Maven artifact com.mycompany:some-package_2.11 version 1.13.0-SNAPSHOT was not found.
It was not bothering me for a while, but right now Iβm trying to setup Octopus-Jira integration and Octopus doesnβt detect build information pushed for a non-existent (as it shows in the UI) package.
Problem is only reproduced for packages with scala version specified _2.11, others can be successfully searched during the feed test and they are correctly represented in the release information.
Is there any fix tor this?
Octopus server version I use is 2020.5.6
Hi @timur.shagapov.sme,
Thanks for reaching out.
Iβm going to try to reproduce this behavior on my end, but in the meantime please let me know if you have any other questions or information to pass along.
Best,
Jeremy
Hey @timur.shagapov.sme,
Can I get a bit more information about your setup, please?
What are you using to host your maven feed?
What is the file name when you are uploading it? is it some-package_2.11.1.13.0-SNAPSHOT?
Can you also send a screenshot of how it sits in the file structure of the feed?
Are you wanting the version to be 1.13.0-SNAPSHOT, or something else?
By which method are you creating your release? If via octo cli, can you please send me the command youβre using?
Please feel free to DM me anything that need to be private.
Please let me know if you have any questions.
Best,
Jeremy
Thank you for jumping on in, Jeremy!
- Maven feed is hosted on Nexus Repository version 3.27.0.
2 & 3 & 4) Filename is usually something_2.11-1.13.0-SNAPSHOT.jar For snapshots it looks like that:
our release feed:
- The version of release depends on a channel weβre creating release in:
develop channel - release is created with package version x.x.x-SNAPSHOT, but the release itself is called x.x.x-[date][time][commithash], so itβs a new release on each new build.
release channel (sorry for tautology 
) - release is created with version x.x.x[-suffix(if exists)].
BTW we donβt have issue with the deployment itself - it works well and we can download the package on the node, here is an example of how it is referenced in our step template:
- We use octo cli on jenkins agent to create the release, the command is:
dotnet octo create-release --project ${octopusProject} --version ${version} --packageVersion ${packageVersion} --channel '${octopusChannel}'
The version is the same for both ${version} and ${packageVersion} in case of release channel, but for develop channel $packageVersion = x.x.x-SNAPSHOT and $version is x.x.x-[date][time][commithash]
Hi @timur.shagapov.sme,
Thank you for all of the information.
Can you please show me the build information screen (Library->Build Information) for the package in question where it shows all the versions for that specific package ID that have build information?
Here is an example:
Iβm wondering if the package name and versions are identical to the ones being stored in the Build Information tab, as they have to be identical on both parts for it to work correctly.
Please let me know.
Best,
Hi @jeremy.miller, actually there are no Maven build information in our list.
I was suspicious about it, and I checked the pipeline itself and it turned out we havenβt correctly handled octo build-information exit code. I found out that I canβt push any build information for Maven packages because of error 400.
octo build-information --package-id='com.mycompany:something-exploration_2.11' --file='buildInfo.json' --overwrite-mode='OverwriteExisting' --version 1.0.0-RC4
Space name unspecified, process will run in the default space context
Handshaking with Octopus Server: https://my.octopus.url
Handshake successful. Octopus version: 2020.5.6; API version: 3.0.0
Authenticated as: Timur Shagapov <timur.shagapov@mycompany.com>
Pushing build information for package "com.mycompany:something-exploration_2.11" version "1.0.0-RC4"...
There was a problem with your request.
- The package ID contains invalid characters. Examples of valid package IDs include 'MyPackage' and 'MyPackage.Sample'.
Error from Octopus Server (HTTP 400 BadRequest)
Exit code: -7`
I tried removing _2.11 suffix just for test, but it still fails. Looks like colon is not allowed and it prevents from pushing any build info for maven packages since all of them has this colon
Hi @timur.shagapov.sme,
Thanks for all of the information.
I think youβre right, this looks to be an issue with the colon in my testing. Iβm going to speak to our developers and see if I canβt get some more information surrounding this.
Please feel free to reach out in the meantime.
Best,
Jeremy
Hi @timur.shagapov.sme,
Thanks for your patience with this one.
This does appear to be a bug.
Here is an open issue for you to subscribe to to get updates on. Can't Push Build Information for PackageIDs in Maven Feeds Β· Issue #6904 Β· OctopusDeploy/Issues Β· GitHub
Please let me know if you have any other questions or concerns.
Best,
Jeremy
1 Like
Hi @jeremy.miller , I have a question regarding the second issue - were you able at that time to reproduce the issue with Maven packages being marked as βMissingβ if they have _2.11 in their name? Since this seems like a separate issue.
Hey @timur.shagapov.sme,
Sorry, I think I had assumed the only issue was the colon, but I can ask if that schema should be allowed by Octopus and if so I will investigate and open an issue.
Just to confirm, you do want _2.11 to be a part of the packageid and not the version?
For instance PackageName_2.11.1.0.0 , the package Id is bold and the version is code formatted?
Please let me know if you have any questions in the meantime.
Best,
Jeremy
In case of Maven I assume that such approach should work: if there are numbers separated by dots, but they are not preceded with a hyphen, they should be part of the package id.
E.g. this-is-package-id_2.11-1.0.0-RC1 (as you can see the default separator in Maven is hyphen instead of the dot)
Hey @timur.shagapov.sme,
I went ahead and tested it on my end.
Nexus version: Sonatype Nexus Repository Manager
OSS 3.30.1-01
Octopus Version: 2021.1.7316
Maven Feed:
Release:
It looks to work on my end, so this may be something that got fixed between our versions.
Are you seeing something in my setup that I didnβt account for that may be different in yours?
Please let me know.
Best,
Jeremy
I updated my Octopus and Nexus to the same versions like you mentioned, but the issue still persist. Interesting thing - tried to get the package versions from the API, and I actually was able to do that for the release feed (we have two different feeds for standard packages and snaphot ones), but there were no packages with version higher than 1.12.0 (in reality there are a lot of packages with higher version). For the snapshot feed I havenβt been able to get even a single package version.
I used this request:
curl -X GET "https://octopus.my.zone/api/feeds/<feed-id>/packages/versions?packageId=com.mycompany%3Asomething-etl-apps_2.11&take=2147483647&skip=0&includePreRelease=True" -H "accept: application/json" -H "X-Octopus-ApiKey: API-mykey"
Maybe there is a way to get whatβs going inside the octopus there from the logs? So far I only found there records when I tried to search for maven package in a wrong format
Hi @timur.shagapov.sme,
Sorry to hear youβre still hitting this.
When you do test feed within your Library->External Feed for that snapshot feed, are you seeing packages? If so, can you please show me a screenshot of a step where you are using a package to see how itβs setup? Are you able to curl packages directly from the feed with maven commands outside of Octopus using the same artifact and version?
Please let me know.
Best,
Jeremy
Hey @jeremy.miller , sorry for delay - no, I canβt see any packages in the UI when trying to list them via Library->External Feed for both feeds (and API calls only return incorrect list for the release feed and empty list for snapshot feed). The artifact is available outside of Octopus UI, even Octopus server is able to download it during deployments itself.
The step is based on a script step template with package reference:
And in the project it is referenced like:
Hi @timur.shagapov.sme,
Thanks for all of the detail.
I think we should probably focus on the packages not showing up in the feed test as our first step.
As you can see here when I search for a known package named similarly to yours, it works:
Here is how I have my feed setup:
I am an admin within that nexus repo.
Can you please check to make sure your feed settings are correct, and then show me what you get when you try to search for a known good package?
Best,
Jeremy
Here is my feed setup:
I have a specific readonly user for Octopus in my Nexus, but just for testing purposes I gave it admin permissions.
Here is me trying to find existing package without _2.11:
With _2.11:
Do you host your Octopus Server installation in docker? In my case this is a usual application running under Windows Server 2019 with DB hosted in AWS RDS (Microsoft SQL Server 2017)
Hi @timur.shagapov.sme,
Thatβs definitely strange that weβre getting different results if weβre on the same versions of both Octopus and Nexus.
I am running my reproduction in cloud, so yes itβs a docker container. I can attempt to run it as a regular windows application and update you with my results.
Just to confirm, you are still on version 2021.1.7316?
Best,
Jeremy
Hey @timur.shagapov.sme,
Iβve spun up 2021.1.7316 on a Windows Server 2019 VM as a normal app, and I am able to see the package with the same feed and test.
It might be worth digging into your pom/xml on your maven feed between that working test and the nonworking one above. There might be some difference in the appender vs -etl-apps that we havenβt thought of thatβs causing the search to not work.
Please let me know what you think.
Best,
Jeremy
