As we plan using Github Actions for pushing deployments to our Octopus server, we’ve experienced some issues using OctopusDeploy/push-package-action@v3.
When running this action on our self-hosted runners, we get an error message saying “Error: unable to get local issuer certificate”. This happens even if our root certificate is installed at the internal runners. Furthermore we’ve tested this using an action curl’ing the Octopus server, without finding any issues. Finally I’ve tested v1 of the same action, and this works fine, also if I set ignore_ssl_errors to false. (No other parameters changed.)
Questions:
Are there any differenses in the way v1 and v3 handles SSL certificates?
Do you have any suggestions for how to trouble shoot this?
Will I be fine using v1 instead of v3, or will the old version be deprecated any time soon?
Thanks for reaching out and welcome to the forums!
Are there any differenses in the way v1 and v3 handles SSL certificates?
I would need to reach out to the developers and get an answer on this one.
Do you have any suggestions for how to trouble shoot this?
This will ultimately come down to a network/cert issue between the GHA agent and the Octopus Server. Is it a dynamic GitHub agent, or one of your own?
Will I be fine using v1 instead of v3, or will the old version be deprecated any time soon?
For push package, I think you are fine to use v1 for the forseeable future. This is a wrapper for octo.exe, which you either have on the agent already or are installing earlier in your GHA workflow, so most of the functionality will come from the version of octo.exe you’re using.
That being said, you might run into similar issues with other Octopus plugin steps that don’t have older versions like Push Build Information.
Looking forward to hearing back on whether its your agent or not.
Thanks a lot for the quick reply. Sorry for beeing unclear about the Github Runners. These jobs are run on our own runners, in order for them to reach the in-house Octopus deploy server.
I did get confirmation that v1 and v3 are completely different in terms of SSL handling.
They recommend troubleshooting by using this command openssl s_client -CApath /etc/ssl/certs/ -connect youroctopus.com:443
You can continue to use v1 of the step, but as mentioned before, you will likely want to get this fixed long term at some point as there might be new step types or new versions of steps that might require this to work without issue.