-
Notifications
You must be signed in to change notification settings - Fork 3.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SyntaxError: Unexpected token '?' on Amazon Linux 2 CodeBuild images (Node 14 required starting at 2.28.0) #20739
Comments
Im getting this and its super annoying, it's because the new cdk version 2.28.0 requires nodejs v14+. Unfortunately, Im using AMAZON_LINUX_2_ARM_2 and that build image doesn't even have the option to use a more recent version. First attempt at workaroundIm attempting to use the 'n' command as below: Second attempt at workaroundIs to pin the cdk version to the previous version rather than use ^2.0.0... Im trying that now. Nope doesn't work as per beton's comment PLEASE AWS can you upgrade all your build images to support cdk, namely nodejs 14+ |
I think this is because of the NodeJS version 12, as I can reproduce it with Node 12 but not with Node 16. When using the CDK with Node 12, I get the warning:
The problem is that when deploying to production, the standard CDK Pipeline image (for ARM anyway) is outdated! The latest version of Node in the AmazonLinux2 package repo for ARM is still 12! Plus, even if you try to pin the version of the CDK in your build, the built-in
which then prints the above warning, and proceeds to fail with the error cited in the original post for this issue.
Please update the |
Nope my prod CI CD is now toast. As per bentons comment the self mutate phase seems to default to installing latest cdk only... perhaps there is a way to override that behavour but im not aware of it.... |
@tmitchel2 not sure if there is anything we can do if its installing the cdk on its own? I did notice that the |
Next attempt from me at workaround is
Ok no that didn't work so Im hoping that turning off selfMutation works...last temporary option i think. |
@tmitchel2 my thought was to use the partial build spec to uninstall 2.28.0 and then install 2.27.0 not sure if that is possible. It's not clear to me if the partial runs before or after the command that ends up installing 2.28.0:
|
@wr-cdargis yup im seeing about that also.... i think i've been mucking up my testing though as im not deploying from my local machine to update the pipeline as this is one of those chicken and egg cdk issues. |
What helped me is installing hardcoded version of cdk in buildspec file: |
Disabling the self-mutation feature of the Pipeline, and then deploying the Pipeline manually, successfully gets past the (non-existent) mutation step. But apparently the
I see that the x86_64 images are also limited to Node 12. |
I think all but Ubuntu standard:5.0 would be broken? noice. |
This works! :). needs a manual push...
|
Nice - I also see Or better yet, maybe just pin the version with the |
Yes i just saw that,,, im going to try moving it into codeBuildDefaults as i think that applies to all.... |
Pinning with |
How do you pin? |
I moved your partial build spec to CodeBuildDefaults. .NET:
|
Ah ok i thought you managed to pin the version of cdk... yup looks like that works :) And the final for others using typescript
|
@tmitchel2
Any ideas how to get the workaround you proposed working with CdkPipeline as well? |
I guess the 'workaround' is to upgrade to latest cdk? |
I don't get your idea - the latest version is 2.28.1 and I am still experiencing the issues described here for 2.28.0, so I think I still need a workaround using another build image and partial build spec as you described before ... |
I presumed you were using an old version because CdkPipeline is old and deprecated now. You just need to change you code to start using CodePipeline instead. |
OK, got your idea:
|
what worked for me is pinning the CDK version from the Pipeline construct. Afterwards do a manual
|
## Motivation aws/aws-cdk#20739 ## Change Pin CDK version to 1.159.0. Once CodeBuild starts supporting NodeJS 14 LTS, this can be removed. ## Result Self mutation succeeds.
## Motivation aws/aws-cdk#20739 ## Change Pin CDK version to 1.159.0. Once CodeBuild starts supporting NodeJS 14 LTS, this can be removed. ## Result Self mutation succeeds.
the issue solved for me, when I upgraded to the latest version of AWS CDK
after upgrading I got this error: |
I tried it with this code snippet but it fails in the NPM Build stage on the second pass (after NPM_Build runs and succeeds, UpdatePipeline runs and succeeds and the NPM_Build runs again and fails).
Our node version is 14.x
|
@ashishchandr70 sorry it's unclear at what phase your pipeline is failing? Also are you running on an AL2 image? |
Hi @MrArnoldPalmer - please see this image. On triggering the pipeline, the Build stage and UpdatePipeline stages work. The UpdatePipeline is set to self mutate and it retriggers the build stage for a second pass. That is when it fails again. Our build image was set to version standard:4.0 but I had to manually update it to aws/codebuild/standard:5.0, which is an Ubuntu image. |
@MrArnoldPalmer I tried setting the const sourceArtifact = new Artifact()
const buildArtifact = new Artifact()
const project = new PipelineProject(stack, `BuildImageProject`, {
environment: {
buildImage: LinuxBuildImage.STANDARD_5_0,
privileged: true,
},
buildSpec: BuildSpec.fromObject({
version: "0.2",
phases: {
pre_build: {
commands: [
"echo Logging in to Amazon ECR...",
"aws ecr get-login-password --region $AWS_DEFAULT_REGION | docker login --username $USERNAME --password-stdin $REPOSITORY_URI",
'TAG="$(echo $CODEBUILD_RESOLVED_SOURCE_VERSION | head -c 8)"',
'IMAGE_URI="${REPOSITORY_URI}"',
'IMAGE_URI_TAGGED="${REPOSITORY_URI}:${TAG}"',
'IMAGE_URI_LATEST="${REPOSITORY_URI}:latest"',
'CONTAINER_NAME="${APP_NAME}"',
],
},
build: {
commands: ['docker build -t "$IMAGE_URI_TAGGED" -t "$IMAGE_URI_LATEST" .'],
},
post_build: {
commands: [
'docker push "$IMAGE_URI"',
`printf '[{"name":"%s","imageUri":"%s"}]' "$CONTAINER_NAME" "$IMAGE_URI_LATEST" > ${imageFileName}`,
],
},
},
artifacts: {
files: [imageFileName],
},
}),
})
const buildActionConfig = new CodeBuildAction({
actionName: `BuildImage`,
project: project,
input: sourceArtifact,
checkSecretsInPlainTextEnvVariables: true,
environmentVariables: {
AWS_DEFAULT_REGION: {
type: BuildEnvironmentVariableType.PLAINTEXT,
value: stack.region,
},
REPOSITORY_URI: {
type: BuildEnvironmentVariableType.PLAINTEXT,
value: this.ecrRepository.repositoryUri,
},
APP_NAME: {
type: BuildEnvironmentVariableType.PLAINTEXT,
value: serviceName,
},
},
outputs: [buildArtifact],
type: CodeBuildActionType.BUILD,
})
/* --- the pipeline config --- */
{
pipelineName: `${serviceName}-Pipeline`,
selfMutating: false,
crossAccountKeys: false,
cloudAssemblyArtifact: buildArtifact,
sourceAction: new GitHubV2SourceAction({
actionName: "GitHub",
owner: owner,
repo: repo,
oauthToken: SecretValue.secretsManager(...),
output: sourceArtifact,
branch: branch,
filters: filters ? filters : defaultFilters,
}),
synthAction: buildActionConfig,
cdkCliVersion: '1.159.0',
} Does that give an idea what could be wrong? Please let me know if there's more info I can provide. |
Is it possible that my old config is getting cached somewhere and that cache is not being invalidated when I create a new build? I'm looking at the build details for the failed and I can see that the build spec and environment don't actually correspond to what's in my code. Any ideas how I can investigate this? Please bear with me I'm filling in for someone else and this is not my area of expertise. |
This breaking a few related projects like the Simple Forecast Solution. For now we are fixing the version to the pervious version or cdk2.28. |
Any insight on this from the AWS team? |
@CodeWithOz I don't believe that is possible. Are you having similar failures to @ashishchandr70 where build step is failing after sulf-mutating? @ashishchandr70 cdkCliVersion dictates the version inside of the self-mutating a synth actions. For your synth action config pass |
Thank you @MrArnoldPalmer . Our Our pipeline, like I pointed out in my earlier response, does (now, after reading one of your replies on this issue) have a
I did notice that the
As you can see, the install command will probably install the latest version of aws-cdk. Similarly, the Assets stage also has a default buildspec:
I think this may be my issue and I will need to not rely on the default buildspec but pass a custom buildspec via our code. |
So here that the When creating a minimal pipeline stack like so:export class Issue20739Stack extends cdk.Stack {
constructor(scope: cdk.Construct, id: string, props?: cdk.StackProps) {
super(scope, id, props);
const sourceArtifact = new codepipeline.Artifact();
const cloudAssemblyArtifact = new codepipeline.Artifact();
const sourceAction = new codepipelineActions.GitHubSourceAction({
actionName: 'Source',
output: sourceArtifact,
owner: 'mrarnoldpalmer',
repo: 'my-repo',
oauthToken: cdk.SecretValue.secretsManager('mygithubtoken'),
});
new pipelines.CdkPipeline(this, 'Pipeline', {
cdkCliVersion: '1.100.0',
cloudAssemblyArtifact,
sourceAction,
synthAction: pipelines.SimpleSynthAction.standardNpmSynth({
sourceArtifact,
cloudAssemblyArtifact,
environment: {
privileged: true,
},
}),
});
}
} The output template shows the buildspec output for the UpdatePipeline step to be
And without the Did you manually deploy the pipeline stack from your machine (or another that has Node 14 +) after making the change? |
@MrArnoldPalmer I am using the CodePipeline so the pipeline is only being deployed there, not from my local machine. It fails even at the Build stage. The image we were using was I also wanted to re-state that we had upgraded our Dockerfiles to use Node.js 14 since the initial reports around this issue pertained to removal of support (from AWS) for Node 12 and below. So all of our images are building with Node.js 14. This is my code
|
@ashishchandr70 all of the above posted fixes require a manual deploy as self-update can't run synth successfully to make the changes to the code to change the cdk cli version or update the containers to standard:5.0, after that deploy it will be able to self-update as usual again. Closing this out as codebuild has made AL2:4.0 available which has NodeJS 16 as standard, so users wanting to continue to use AL2 with the latest CDK CLI should be able to. If you get stuck with this error in self-update, update your codebuild images and run a deploy of the pipeline stack to get the updates. |
|
@MrArnoldPalmer AL2_4 is only x86 and not arm so ideally shouldn't be fully closed out. |
Since there is no information on when NodeJS 14 will be available on the provided ARM images, I think our best bet would be to write some logic to detect when a cdk pipeline is building/self-updating/etc on an arm image and automatically add the steps to install node14 to the buildspec. @tmitchel2 wanna open a new issue for that? You may also have a better alternative in mind. |
My workaround as per above works for me and is fine enough as a workaround, however, I just wanted to make it clear that the Arm images are getting left behind a bit and I guess still need to be addressed. |
Describe the bug
Running command
cdk synth
with latest aws-cdk from npm produces an error.Expected Behavior
I made no changes to source. The install step installs the most recent
aws-cdk
and it seems this error came with the newest version.Current Behavior
Reproduction Steps
Possible Solution
No response
Additional Information/Context
I was able to explicitly install version 2.27.0 to confirm this is an issue with 2.28.0 (but I still have this problem later in the self mutate phase where I can't control the version). This was all done on a .NET CDK app. My apologies for the lack of info I know you need more I am just trying to get some attention on this as soon as I can.
CDK CLI Version
aws-cdk@2.28.0
Framework Version
No response
Node.js Version
12.22.12
OS
Linux
Language
.NET
Language Version
No response
Other information
No response
The text was updated successfully, but these errors were encountered: