Code has been tested and can now be deployed. (Didn't want to deploy on a Friday night then run away for a month!)
This has now tested successfully. To create failed cases, modify the SQS secrets in DEV so the queue becomes uncontactable. Once you have a failed case, you can revert your changes and run the cronjob, which will successfully resubmit. When previously deployed to DEV, the cronjob correctly identified FAILED jobs and kicked off the resubmission process but couldn't proceed past the "transform and upload" task. Would appear this error was down to me fudging appplications into a failed state, so creating test applications as described above is the way to go rather than altering the DB.
If merging to Prod, the cronjob will also need to be manually deployed. To do this, go to the prod cronjob folder locally and run kubectl -n claim-criminal-injuries-compensation-prod apply -f resubmission-failed-check-v2.yaml. You can run kubectl -n claim-criminal-injuries-compensation-prod get cronjobs to check it successfully runs.
Our DEV environment has been fully configured to use AWS secrets manager instead of manually applied secrets.
This is now ready to be replicated across namespaces. This can be done by copying the DEV setup to other namespaces and copying the secrets from our sharepoint folder into the secrets manager via console.
The cloud platform user guide explains this process well. Worth noting though, doing this on production will likely require downtime to be safe.
Similar to our secrets, our cloud platform DEV environment has been configured to host our cronjobs. Neither staging nor UAT require any cronjobs to operate (DEV and UAT use the same RDS and staging is, at time of writing, gubbed). These could be replicated to production by copying the necessary yaml files across environments.
Raised as part of the ITHC. There were a number of issues with the push gateway pod. This is created by a terraform file in our prod environment. This file uses a cloud platform repository as a source. In order to address any of the issues raised by the ITHC, the source Repo will need to be updated with a more up-to-date helm chart (I reckon they're on 1.5.0, the latest is 1.6.2). I believe this has been included in an email forwarded to the cloud platform, but if not it could be raised as an issue
As posted in dev chat, curl is cutting a release to deal with a high severity CVE. Our cronjobs use an image which installs curl. This image is built, tagged and pushed to the ECR so it can be used by the cronjobs in exactly the same way our maintenance page is handled. The update for curl is due to be released on 11th October. Following this, we will need to update the above image with the new build.