Thanks for getting in touch and my apologies for the delay in responding. You mentioned you updated “Bamboo version to the latest version”, just checking you meant the plugin version?
Could I check which version of Bamboo and which version of the plugin you have? I’ve tested and can’t reproduce any issue, but maybe I’m using a different Bamboo version.
Also, are you running Bamboo on Windows or Linux? And which version of Java etc do you have?
I think I’ve found the answer, I wasn’t aware that you could add our steps to a Deployment project. Is that where you have your steps?
We designed the plugin for use in the Build projects, especially the Metadata step as it requires access to the commit details and that isn’t available in a Deployment project, at least not that we can find.
I tested it this morning and got the same exception you are seeing. The DeploymentTaskContextImpl is what gets passed to us in this case and it doesn’t have the method to get the commit details, which causes the exception.
Shannon- yes we are using it in a deployment step. We run all the Octo steps there. The reason is that we like to use automatic branch building and we put all of our deployment steps in deployment projects. That way- automatic branch builds will ONLY build (if you add deployment steps in the build plan- EVERY step is always executed even if you don’t want them to be - say like you don’t want to deploy a feature branch, but you do want it automatically built).
However, according to Bamboo documentation, the commit information IS available to deployments via releases. I haven’t checked the API, but I can see it in the UI here:
Can you check out the API and see how they are getting it? We REALLY want to keep our deployments (to Artifactory and Octopus) in Bamboo deployment steps, but we also REALLY want that metadata in Octo so we can do automated release approvals and notifications from Jira.
I’ve checked and the APIs we have access to inside the plugin framework do not expose the build or commit details anywhere we can get to them. I think what the UI has access to there is a much richer world.
We agree that the Octopus deployment steps (Deploy Release and Promote Release) make sense in a Deployment project, and they should actually work fine there as well as in a Build project. The Package Metadata step though is very much concerned with the 1 time build of the binaries in a Build project, just like Pack, Push, and Create Release.
I’m in the process of updating the plugin to detect when it’s being run in a Deployment project and report a better error message.