search

aws-actions / setup-sam

Action to set up AWS SAM CLI and add it to the PATH
Apache License 2.0
151 stars 23 forks source link

Node 20 - Breaking Change? #97

Closed MaartenTutak closed 8 months ago

MaartenTutak commented 8 months ago

Hi,

we noticed our builds failing (using setup-sam@v2) this morning because we have no support yet for Node 20 on our self-hosted runners. Our current workaround is to target a specific commit hash right before the upgrade to Node 20.

Screenshot 2024-02-01 at 11 33 19

Perhaps you should consider releasing this change as a V3?

Thanks, Maarten

jkruse14 commented 8 months ago

This has broken our builds for self-hosted runners as well.

jkruse14 commented 8 months ago

@rivierch @jfuss - it looks like #96 was merged into tag v2 - are you able to help resolve this by removing the commit and creating a new v3 tag?

jfuss commented 8 months ago

@jkruse14 I am talking with the team now. I don't understand why this affected self hosted runners but we were using a very old version of Node. So my advice is either update to Node20 or lock to a hash, at the moment. I know this isn't the best answer but we need to weigh what is best to do.

jfuss commented 8 months ago

Chatted with the team. We are going to leave this at v2 and not revert/release a v3.

Thought process: This impacts Self Hosted runners that do not install Node20. Github hosted runners have Node20 installed. If we were to revert, we would be back to using a Node version (16) which is not longer supported as of Sept 2023. In addition, pushing a v3 would require everyone to upgrade instead of only customers locked to an unsupported Node Version.

If you are impacted, your path forward is to install Node20 onto the system or lock the github action to 8aee2f4a7fe48544e1468ff08d28b88b99021291 by updating aws-actions/setup-sam@v2 to aws-actions/setup-sam@8aee2f4a7fe48544e1468ff08d28b88b99021291. We understand this isn't ideal for impacted customers but believe this is the best path to take.

jkruse14 commented 8 months ago

@jfuss - Thank you for the information and the steps to move forward. While I understand the reasoning behind the decision to leave this commit in the v2 tag, I would like to say that this is not good, nor standard, practice. This is a breaking change, in such a case the best practice would be to bump the version. Previous releases of software should only change patching purposes, not for breaking changes.