Hi Kari,
Just an update.
I’ve chatted with @Shawn_Sesna who has mentioned he has been meeting with you around 1-2pm PST, if that time is suitable for you I would like to arrange a call where we can run through your configuration and process together.
You can schedule a call via this link, please let me know if there are any issues with it:
https://meet.goodtime.io/w/octopuscom/finnian.dempsey/octopussupport
Looking forward to getting this resolved!
Best Regards,
I met with Tamra and Shawn and I will work on getting this step added. Thanks! IU will post the results next week.
The main topic we discussed was regarding your reported bug about work items from the builds not showing in Octopus releases with Version 4 of the “Create Octopus Release” step.
Shawn noticed that your build process did not contain a “Push Build Information” step and that the Build Information portion of Octopus Deploy was blank. The Release Notes template that support suggested relies on the information from the Build Information portion of Octopus to populate the notes, which is why the template didn’t work. The “Push Build Information” doesn’t require you to build this yourself. The step will gather the commit information for you and supply it to Octopus Deploy. For Work Items, the Azure DevOps issue tracking will also need to be configured. Please see this documentation on Build Information which should help with the setup and potentially fix your issue. Please keep me posted on how this goes!
Hi Kari,
Apologies for all the confusion with this thread!
It sounds like you are configuring the new method of pushing build information in a seperate step a Shawn and Tamra suggested, rather than using the legacy method. This is definitely our recommended approach!
Looking forward to hearing how you went or if you run into any issues getting it configured!
Best Regards,
I have used the documentation here: Build information - Octopus Deploy
to add the Build Information Step.
The TFS builds are failing with a SSL certificate issue. We do not want to ignore using ssl.verify = false.
I Found more documentation here: Using the Octopus extension - Octopus Deploy. This also is not working for us.
We are considering moving back to Version 2 of the [“Create Octopus Release” step.] so that we can resolve this issue.
Hi Kari,
Because you are experiencing an SSL error, I believe you might have been effected by a recent Azure change regarding TLS, you read about the changes and scheduled dates in their post: Deprecating weak cryptographic standards (TLS 1.0 and 1.1) in Azure DevOps Services - Azure DevOps Blog
If that’s not the case I’d be happy to explore the issue further! Could please send through the logs for a failed build?
In regards to the Publish package artifact step, it’s typically used to allow another process access to a created package/resource. Generally this is because of having the Build and Release processes seperate, which doesn’t appear to be the case for you based on the previous image showing a Create a Release step directly following the creation of the package in the same process:
Could you please expand on what your use case for this step? There might be another option that could work better, I’d be happy to schedule a call to discuss this!
Feel free to reach out if you have any questions!
Best Regards,
Hi Kari,
Confirming our call for tomorrow, I have also invited Shawn to join!
Our engineers have also been exploring the TLS deprecation and have found that the issue appears to be caused by the TLS protocols being negotiated on the instance with the transport protocols TLS 1.0, TLS 1.1 and some TLS 1.2 cipher suites being deprecated.
Azure has provided a useful script to run to confirm if a machine is TLS1.2 ready, which combined with IISCrypto to adjust the available protocols/ciphers, you should be able to ready an instance for TLS1.2 and resolve this issue. This will need to be performed for any Octopus/Tentacle instances.
The announcement I linked earlier implies that 2 different tests are being run with the changes being permanent after the 31st of March. It might be the case that it begins working again temporarily!
Looking forward to meeting and getting these TFS issues resolved for you!
Best Regards,
Hi Kari,
Thanks for meeting with me today, just a quick summary of the conversation and proposed next steps.
Next Steps:
Apologies for not requesting this during the call, would you be able to please also send through the build logs for that successful run? (using the Legacy method with version 2).
I’ll keep you posted with any updates or suggestions, feel free to let me know if you have any questions or any of the above isn’t correct.
Best Regards,
Hi Kari,
Thanks for sending that through, confirming that I have received it ok. Hope you had a nice dinner with your son!
I’ve requested assistance from the devs regarding the issue that is appearing for version 4:
An exception was thrown while building the release notes.
{ Error: unable to get local issuer certificate
at Error (native)
at TLSSocket.<anonymous> (_tls_wrap.js:1092:38)
at emitNone (events.js:86:13)
at TLSSocket.emit (events.js:185:7)
at TLSSocket._finishInit (_tls_wrap.js:609:8)
at TLSWrap.ssl.onhandshakedone (_tls_wrap.js:439:38) code: 'UNABLE_TO_GET_ISSUER_CERT_LOCALLY' }
See "https://github.com/OctopusDeploy/OctoTFS/issues/107 for more details."
I’ll keep you posted with any updates or suggested actions, looking forward to getting this resolved!
Best Regards,
Hi Kari,
Just an update. The devs are looking into this and would like to rule out any potential TLS issues, as both the warning: Use Cipheriv for counter mode of aes-256-ctr as well as the error Error: unable to get local issuer certificate indicate TLS.
Also the issue mentioned in the logs doesn’t seem to match the error you are seeing and so we think this is misleading, rather than indicative of what’s going on.
Our recommended next steps:
Let me know how you get on or if you have any questions!
Best Regards,
Thanks, Finnian. I will need to get a test environment set up to run the script. We are currently moving to a high-availability mode and our test env is in a bit of flux at the moment.
For the Octopus plug-in to version 5, I don’t think that is high risk and can probably be installed directly in our prod env. I’ll work on getting that done tonight.
Thanks!
Regarding this… it looks to be an Azure DevOps update. We are TFS2018 - is the version 5 available with TFS 2018?
Hi Kari,
No problem at all, let me know if you have any questions setting up your test env!
The Azure Devops plugin version 5 is available for TFS 2018, you should be able to navigate to it in the marketplace to install it but let me know if that doesn’t work. It does come with some significant changes, most important is that it is no longer bundled with the OctoCLI and so any ‘Octo Pack’ steps will need to be changed to another package ‘packing’ step, such as npm pack. I’ll test the upgrade path on my local reproduction to confirm what changes will be required!
I actually believe I have reproduced the issue! It seems that when I launch a build using a specific commit message as you were doing during the call, I wasn’t able to get my release notes to be present.
Are you able to please test queuing a new build using the git cli and confirming if you have any issues? (presuming you have your builds triggered from a commit)
e.g. git commit -m "Fixes #7 test commit"
I’ll keep exploring this and let you know if I have any updates!
Best Regards,
Thank Finnegan. Our test environment is working now. I will get the newest plugins installed. I will aslo need to get git installed. Pun intended.
Hi Finnegan,
Wow, this has gone on for months now. Perhaps we are close.
I will not be installing git as our developers do not use cli git but visual studio. They do commits by pushing into TFS which is a git repository. As a DevOps engineer, i can commit directly in TFS.
We do not use any OctoPack steps but we do use “Package Application for Octopus”. I am hoping we can get this to work without using npm pack which requires a package.json for each step. Creating package.json for all our projects would take longer than having our project managers identify work items manually.
I download the updated plugins and changed steps to Version 5. This version required a new TFS build Agent version of 2.1.44 which I downloaded and installed. Now get an error that TFS Build Agents needs to have a capability of octo Please let me know where to download this module to our build agents.
Please advise. Let’s set up another meeting and see if we can bring this to resolution please.
Hi Kari,
I really appreciate your patience, I feel we are very close to resolving this and one more call should do it!
I’m sorry for all the headaches and confusion with these latest changes, it’s definitely outlined areas we need to improve, such as listing any major changes publicly which can now be found at: https://github.com/OctopusDeploy/OctoTFS/releases.
I have just met with the developers, going over the entire process and we have raised an issue with the Plugin, which will prevent you from using the new “Push Package Build Information” step for your Build Information as we were suggesting. They are looking into resolving this and I’ll let you know when it’s fixed.
In the meantime, you will need to use the Legacy method, where the work items are included in the Release.
I’d be happy to run through your configuration and make sure it’s all correct and the right info is coming through, you should be able to use the same link to schedule a call: GoodTime - Let's find a good time to meet!
Let me know if the times aren’t suitable or there are any issues with it at all. Looking forward to meeting again and getting this resolved!
Best Regards,
Hi Kari,
I just noticed while checking the logs that “Ignore SSL: false”. Could you please double check if this i enabled and whether changing it resolves the issue?
I’ll keep exploring and keep you posted with any more findings.
Best Regards,
Hi Kari,
I found this issue which I believe describes what’s going on with node:
TLDR: Corporate Firewall/Proxy - Most likely a TLS certificate in the chain is signed by an unknown CA, likely the cert your proxy uses.
Secure Options to Resolve:
export NODE_EXTRA_CA_CERTS=/path/to/your/CA/cert.pem (This can just be a Pipeline variable)
npm config set cafile=/path/to/your/CA/cert.pem
Another option for resolving this is covered in this blog, where they suggest using git config --global http.sslCAInfo C:/Users/username/ca-bundle.crt
Another option could be to force node to use the openssl config with the node runtime option --use-openssl-ca although I’m not sure if this is considered secure or not.
Insecure Options for testing only:
npm config set strict-ssl false
export NODE_TLS_REJECT_UNAUTHORIZED=0
git config --global http.sslVerify false
Looking forward to the meeting tomorrow and getting this resolved!
Best Regards,
