I’m setting a fresh install of Octopus to replace an older version 1.6 installation. We use Jenkins and ProGet along with Octopus for CI and deployments. The following line uses octo to create the release from the powershell script used for builds:
exec { & $tools_dir\octotools\octo.exe create-release --project="$octopus_Project" --server=$octopus_API_URL --apiKey=$octopus_API_key --packageversion=$ReleaseNumber --version=$ReleaseNumber }
and the release gets created. However, the Octopus NuGet server does not seem to index the new packages. So far, only restarting the Octopus Windows service seems to make the packages accessible so that a deployment can be initiated. Not an ideal solution.
When the octo command runs, the nuget packages are placed into the root folder associated with Octopus API url. This is consistent with the behavior of version 1.6. However, there are folders created for each package in the release. In the case of this app being deployed, there are 7 nuget packages the comprise the release. Restarting the Octopus service moves the nuget packages into their respective folders which makes them visible to the new repo. Is there some setting in octo.exe or perhaps in octopus nuget server that will cause the packages to make it into the sub-folders automatically?
Thanks for reaching out. It definitely shouldn’t be necessary to restart the Octopus Service in order for this to work.
When Octopus creates the release, it looks for the package on the feed. Meaning that at that point, the package should be available on the feed. You mentioned that “the nuget packages are placed into the root folder associated with Octopus API url”. Which directory is this exactly?
If you are using Proget as your package repository, you should only be pushing the NuGet package the Proget before you create the release, and then have Octopus consume your Proget feed.
This is a single server hosting Jenkins, Octopus, and will soon have ProGet and this server will be replacing an existing one with a similar setup. We are not using ProGet for the deployment packages. ProGet is only used to host the nuget packages we develop internally for shared functionality across projects. The root folder that the Octopus Api url points to is simply C:\NuGets.
Thanks for the extra info. I forgo to ask you a very important question: This new installation is also a 1.6 Octopus server, or are you using a newer version?
Thanks for the clarification. Yes, in 3.0 the directory that holds the packages (by default C:\Octopus\Packages) will have a subfolder with the ID of the nuget package, and inside of it all the versions of that package. So for a package with the ID TestConfig, the full path would be C:\Octopus\Packages\TestConfig\TestConfig.1.0.0.nupkg, C:\Octopus\Packages\TestConfig\TestConfig.2.0.0.nupkg, etc.
You can change the root folder, but not the sub-folder schema.
Yes, I’ve seen that it now works that way within Octopus Deploy. The problem is that the octo tool does not seem to honor that. When you run that with the create-release command, it puts the nuget files in C:\Octopus\Packages, not in C:\Octopus\Packages\TestConfig. And since they’re not in the sub-folders, Octopus shows FileNotFound errors.
I have continued to fight with this issue all week. I suspected that the issue may have been because i changed the root path of the internal Nuget repository from C:\Octopus\Packages to C:\Nugets (the folder structure we had working with version 1.6), so I changed it back to the default folder structure. This did not help. So I installed ProGet on the server and setup a package feed for the build outputs from our Jenkins CI jobs. I set that feed up as an external feed in Octopus with multiple variations, but no matter what I did, I could not get Octopus to include the packages from this feed without a restart. So I went into the feed in ProGet and overrode the default Disk Path so that it is now C:\Octopus\Packages. After a build, the packages end up in the package sub-folders of C:\Octopus\Packages as they should. However, Octopus still does not see them until after a restart!
This has me wondering if the indexing of this folder is some scheduled task in Octopus that is not occurring except during service startup? Could that be the case?
At this point, I feel I have exhausted all my options with this software. If we can’t come to a resolution soon, we’re going to have to look at other options.
I think it’ll be best if we troubleshoot this on a call while sharing your screen. If you are up to it, please select a date from this link https://calendly.com/dalmirogranias
Thanks Dalmiro, I think doing the screen share would help. I looked at the link for your calendar. It appears that Monday is not a day where this is offered?
I signed up for a time slot for tomorrow, but just as an fyi, Today was not an option when I looked at the link Friday or I would have booked one of those.
I upgraded to version 3.0.19 and retested a deployment. The updates did not resolve the problem. Could plan to do another screen share tomorrow when we are both in the office?
Same issue here. Standard OD install. New packages pushed to c:\octopus\packages (via Octopack) are not indexed by OD until the OD service is restarted. Is there a fix in the works for this?
Thanks for reaching out. I’ll be meeting with Tom (ticket owner) today to check his environment and try to see what might be going on. If it turns out to be a bug, we’ll submit it on github and get it fixed as soon as we can.
In the meantime, could you please provide me the following info?
Exact version of Octopus you are running
Your Octopus server logs (C:\octopus\Logs by default). You can send them to Support@Octopusdeploy.com to keep them private.