ADF support for CDK v2
Hi,
According to cdk documentation support for CDK v1 will end entirely on June 1, 2023. I can see that the latest version of ADF has references to CDK v1 (v1.188.0).
Is there any plan to update these construct libraries to cdk v2?
Thanks.
What a coincidence!
We have been blocked by not being able to use the STANDARD_6_0 images as part of our pipelines due to CDKv1, so this morning I spent some time creating a patch for our ADF installation that updates to CDKv2 (see linked pull request) that we now have deployed to production.
Nodejs 14 is officially being deprecated as a Lambda runtime by AWS and are now blocking new Lambdas from being created and/or updated as of January 9th and February 8th respectively, see this page.
This is causing a path to production issue for us (and I'm sure others?) as we're not able to use later CodeBuild images that support LTS versions of Node in pipelines with the current version of ADF.
@pergardebrink - your patch, would this be a simple fork from ADF master, copy the code over to a branch from our main and merge? We're thinking we have to deploy an emergency change to get us back up and running but being a relatively junior engineer, getting a deployment plan together is challenging with it not being an official release.
@sam-netlogix it was a while since I developed that code for the CDKv2 pull request and don't remember exactly what adoptions I had to make for our internal ADF version compared to what I contributed what I got merged here (I think we were at 3.1,2).
What version of ADF are you at currently?
I would most likely have done something similar like you suggest, to put the changes from this repository related to my PR in a branch, but I would observe closely what changes is introduced in that branch (and skip all not-related ones). But there are some risks and in our case, we have a "dev" ADF setup that we run all our tests on that I would have used.
@sam-netlogix it was a while since I developed that code for the CDKv2 pull request and don't remember exactly what adoptions I had to make for our internal ADF version compared to what I contributed what I got merged here (I think we were at 3.1,2).
What version of ADF are you at currently?
I would most likely have done something similar like you suggest, to put the changes from this repository related to my PR in a branch, but I would observe closely what changes is introduced in that branch (and skip all not-related ones). But there are some risks and in our case, we have a "dev" ADF setup that we run all our tests on that I would have used.
We're at v3.2.0 currently, the noteworthy customization's we've made are creating our own CDK packaging script as suggested by the documentation and we also cloned the aws-deployment-framework-bootstrap repo from CodeCommit to GitHub and edited the aws-deployment-framework-bootstrap-pipeline source to be that GitHub repo instead.
Am I correct in thinking that a "dev" setup of ADF would require an entire separate AWS Organization? That would be very handy but isn't something we have currently so we have to be very cautious making changes to ADF, hence my reservations.
We're at v3.2.0 currently, the noteworthy customization's we've made are creating our own CDK packaging script as suggested by the documentation and we also cloned the aws-deployment-framework-bootstrap repo from CodeCommit to GitHub and edited the aws-deployment-framework-bootstrap-pipeline source to be that GitHub repo instead. We did a similar move.
If you're at v3.2.0, the changes pulled from my PR would most probably be possible to get a branch for. I don't know the best way to do it.
Note that I don't take any responsibilty on following my advice here, but if you are ok with not including commits from this repository (just the actual changes), I think you could pull something off like this (No guarantees!!, only how I probably would have done in our test environment before going to prod):
- Save the contents of this patch (this is all the changes from the v3.2.0 tag up to the merge commit with my CDKv2 PR on top) https://github.com/awslabs/aws-deployment-framework/compare/v3.2.0...b32326ce1e8cee782b27dd6d4a16d38e1d2bc0f8.patch
- Go to your local bootstrap repo and create a new branch (cdkv2 or whatever you like)
- Apply the patch above
git apply ../path/to/the/patchfile - Now if the patch was successful, the repository should contain 77 files or something like that with all my changes + some other new changes introduced after v3.2.0
- Commit and create a PR and make sure to check the changes looks like what you expect (which is the really tricky part).
- Merge and hope for the best 😬
Am I correct in thinking that a "dev" setup of ADF would require an entire separate AWS Organization? That would be very handy but isn't something we have currently so we have to be very cautious making changes to ADF, hence my reservations.
Yeah, we have a (smaller) replica of our AWS Organization just to be able to test out ADF changes before doing them in prod (which is convenient and made life easier to try things there first). Quite hard to setup after the fact for you ofc.
Oh, I just remembered that the bootstrap repo does not have the same layout as the adf repo here, so the patch above won't work I assume then! Maybe the patch is applicable if editing the paths or something.. I currently cannot access a bootstrap repo to verify, so cannot give you any hints on how to proceed in case the patch does not apply.
Any update on v4 release? This is starting to kill us
Oh, I just remembered that the bootstrap repo does not have the same layout as the adf repo here, so the patch above won't work I assume then! Maybe the patch is applicable if editing the paths or something.. I currently cannot access a bootstrap repo to verify, so cannot give you any hints on how to proceed in case the patch does not apply.
That's correct, it did not apply correctly due to the bootstrap layout being part of src/lambda_codebase/intial_commit/bootstrap_repository/ instead of root. But thank you for the attempted help none the less!
This is why I wondered if just cloning the master branch (or I could even possibly try your branch?) and selecting those files then copying them in to a branch for my bootstrap repo might work. I did this, around 92 files are being changed and some are obviously discard-able like the custom CDK scripts we have in shared/helpers as well as adf.config but the rest are very hard to commit with any confidence as I'm not sure the current state of master branch is in a functional state and/or what of the new features might require param input on deployment that won't be reflected in a manual patching, potentially breaking the entire deployment.
I guess my biggest surprise is that more people aren't now coming across this issue the last few weeks since Node14 is being deprecated for Lambda! Thought I was going to come on to this issue yesterday with a tonne of new comments, but alas 😄
Hi all,
As mentioned in #619, unfortunately we ran into a number of issues that were hard to debug. Hence we did not release the new version just yet.
Regarding the suggestions in the discussion above, I would not recommend to deploy the master branch yet nor a cherry-picked patch version of ADF. Especially not in a production-like environment. Deploying the master branch or a cherry-picked patch version would make it hard to ask for help with issues down the line. As you would be running a customized/unreleased version of ADF.
I appreciate your patience and understanding as our development team is working diligently to ensure the highest quality for this release.
Currently, we are in the final testing phase, and if no major issues arise, we are confident that the v4.0 release will be available within the next few weeks. Rest assured that our team is committed to delivering this update as soon as possible while maintaining the highest standards of quality and reliability.
We understand the importance of this release for our users, and we are eager to share the new features and improvements with you. Please stay tuned for further updates, and thank you once again for your continued support.
Best regards, Simon
Appreciate the update
Thanks
Thank you for your patience. I am pleased to inform you that this feature has been released as part of v4.0.0 just now. I'm hereby closing this issue. Please open a new issue if you are experiencing any issues related to this feature.
Thankyou very much!!
Will update and advise if any issues via a new ticket