We have recently upgraded from Octopus Version: 2018.4.3 to the latest Octopus v2018.9.16, and encountering the following error for one of our projects:
An unexpected error occurred in Octopus v2018.9.16: “TypeError: Cannot read property ‘PackageId’ of undefined”
in t
in div
in div
in div
in div
in t
in div
in div
in div
in div
in div
in div
in div
in div
in l
in div
in t
in div
in div
in n
in n
in Connect(n)
in t
in t
in t
in t
in t
in t
in div
in div
in MediaQuery
in div
in w
in t
in withRouter(w)
in main
in t
in Connect(t)
in t
in t
in t
in t
in t
in t
in withRouter(t)
in t
in t
in t
in t
in t
in r
in t
in t
in t
in t
in t
in x
in div
in t
in Connect(t)
in t
in t
in t
in t
in t
in t
in t
in t
in Provider
in t
in i
in t
HIDE FULL EXCEPTION
Octopus v2018.9.16
TypeError: Cannot read property ‘PackageId’ of undefined
render (/app/components/Actions/windowsService/windowsServiceAction.tsx:30:62)
Lf (/node_modules/react-dom/cjs/react-dom.production.min.js:147:337)
sf:a:{e=b.type;c=b.pendingProps;d=b.memoizedProps;if(nf())null===c&& (/node_modules/react-dom/cjs/react-dom.production.min.js:150:232)
e (/node_modules/react-dom/cjs/react-dom.production.min.js:182:349)
g (/node_modules/react-dom/cjs/react-dom.production.min.js:183:347)
p (/node_modules/react-dom/cjs/react-dom.production.min.js:184:366)
0;null!==a&&c;){c=!1;if(a.pendingWorkPriority===T||a.pendingWorkPriority>b)c=!0,a.pendingWorkPriority=b;null!==a.alternate&&(a.alternate.pendingWorkPriority===T||a.alternate.pendingWorkPriority>b)&&(c=!0,a.alternate.pendingWorkPriority=b);if(null===a[“return”])if (/node_modules/react-dom/cjs/react-dom.production.min.js:188:389)
S (/node_modules/react-dom/cjs/react-dom.production.min.js:187:415)
enqueueSetState (/node_modules/react-dom/cjs/react-dom.production.min.js:140:181)
isMounted (/node_modules/react/cjs/react.production.min.js:12:343)
I have replicated an error similar to yours locally. It does look to be related to the upgrade process between the two versions that you have stated. To confirm, it would be helpful if you could send me the JSON that the server sends back to your browser when you encounter this issue.
By using the developer tools in your browser and filtering on the term ‘deploymentprocess’ you should see a GET request that contains the JSON of the process that is failing to render.
Could you please send me the raw JSON response payload as per this screenshot?
I will also need to know the exact name of the package and which package feed it comes from (e.g. the Built in feed or an external one).
This will help me to confirm the bug as I see it here in my test environment, and enable me to send you a short script to fix the deployment process data.
Could you confirm if this process used to work prior to the upgrade?
I’m going over the JSON here and have noted no package IDs associated with the Windows Service actions (DoverIGLSJE_IGLSAck_Service and DoverIGLSJE_EmailCaseCreation_Service) which indicates they may not have been working before, although it is possible that they were.
If you don’t need these - I can write a deletion script and then you can set them up again (if needed).
Let me know, I’ll assume this is the case for now.
To clarify, the steps that were causing issues are called DoverIGLSJE_IGLSAck_Service Installation and DoverIGLSJE_EmailCaseCreation_Service Installation and the ‘deploy windows service’ actions within those steps ( DoverIGLSJE_IGLSAck_Service and DoverIGLSJE_EmailCaseCreation_Service ) are specifically at fault here.
I have noted that these two actions were also disabled, so I’ll continue to supply you with a removal script for just these two actions as I mentioned previously. If you need them you would need to recreate those two actions.
Do you have prior releases of this process that you would need to re-deploy at some stage? If so, these will likely be broken too and a broader script will be required.
Attached (see bottom of post) is an Octopus.Client Linqpad script that you can modify to suit your environment. It will selectively go over the deployment process that you sent to us, and remove the problematic actions (which were already disabled). It can be run remotely from the server, provided appropriate HTTP(s) access is enabled from the location you execute from.
This should allow you to get back into the deployment process screen and make further modifications as required.
If you explicitly do not want these two disabled actions to be removed, do not run this script - just let us know - we’ll prepare a slightly more complex script that will reconstruct their malformed content.
Please note: There are some commented instructions in the first few lines of the script that require you to set the correct values for your server and API key.
If there are any errors when you execute this script just let us know and we’ll take care of it for you.
For any others potentially bumping into this issue - we’ll be providing an upgrade script to fix this up across the board in due course. You can follow the progress of the overall fix via this GitHub issue.
As per your suggestion, we have successfully executed the script. Now the issue has been resolved in OCTOPUS deploy. We can able to see all the process steps which we had created earlier.
Deployments!