Skip to content
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

fix(AWS API Gateway): Ensure shouldStartNameWithService support #10177

Merged
merged 6 commits into from Nov 8, 2021

Conversation

vicary
Copy link
Contributor

@vicary vicary commented Oct 29, 2021

The closing of #8720 was a workaround by supplying an optional option apiName.

In a perfect world it should correctly deploy with the recommended provider.apiGateway.shouldStartNameWithService without having to provide a custom apiName. But the workaround in the issue make it a required option, otherwise the script exits with code 1, and my CI environment is not happy about it.

This PR is a continuation of the discussion I started after the closing of the issue.

For more context please see #8720 (comment)

Copy link
Contributor

@pgrzesik pgrzesik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for contribution @vicary, good catch 👍 I have one suggestion for the implementation that should help avoiding such bugs in the future. Additionally, it would be great to cover this scenario with a test case based on runServerless utility.

@@ -150,7 +150,9 @@ async function resolveRestApiId() {
}
const apiName = apiGatewayResource
? apiGatewayResource.Properties.Name
: provider.apiName || `${this.options.stage}-${this.state.service.service}`;
: provider.apiName || (provider.apiGateway && provider.apiGateway.shouldStartNameWithService)
? `${this.state.service.service}-${this.options.stage}`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of duplicating the logic, we should rather reuse the naming.getApiGatewayName utility - the reason for this bug is that it was not used previously I believe.

@vicary
Copy link
Contributor Author

vicary commented Nov 1, 2021

@pgrzesik Thanks for the review. Sorry for not super familiar with the internal API yet, using naming.getApiGatewayName() now.

I'll try writing a test with runServerless this week.

@pgrzesik
Copy link
Contributor

pgrzesik commented Nov 2, 2021

Perfect @vicary - let me know if you have any questions 💯

@codecov
Copy link

codecov bot commented Nov 2, 2021

Codecov Report

Merging #10177 (34bcac5) into master (254e70c) will decrease coverage by 0.03%.
The diff coverage is n/a.

Impacted file tree graph

@@            Coverage Diff             @@
##           master   #10177      +/-   ##
==========================================
- Coverage   85.38%   85.35%   -0.04%     
==========================================
  Files         339      339              
  Lines       13819    13831      +12     
==========================================
+ Hits        11800    11805       +5     
- Misses       2019     2026       +7     
Impacted Files Coverage Δ
.../compile/events/apiGateway/lib/hack/updateStage.js 95.06% <ø> (ø)
lib/classes/CLI.js 57.14% <0.00%> (-2.86%) ⬇️
lib/Serverless.js 66.96% <0.00%> (-2.51%) ⬇️
lib/plugins/aws/package/compile/functions.js 94.44% <0.00%> (ø)
lib/plugins/aws/provider.js 94.31% <0.00%> (+0.01%) ⬆️
lib/plugins/aws/deploy/index.js 98.68% <0.00%> (+0.05%) ⬆️
lib/plugins/aws/info/index.js 97.22% <0.00%> (+0.07%) ⬆️
lib/utils/telemetry/generatePayload.js 90.90% <0.00%> (+0.43%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 254e70c...34bcac5. Read the comment docs.

@vicary
Copy link
Contributor Author

vicary commented Nov 5, 2021

@pgrzesik It was quite a trip to stub all the way down to after:deploy:deploy, I've learn a lot more about the inner workings nonetheless. Not sure if there is a quicker way though.

Copy link
Contributor

@pgrzesik pgrzesik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks awesome, I have only one minor suggestion and we should be good to go - well done with mocking all these AWS API calls - this one was definitely very tricky case

@@ -809,4 +809,66 @@ describe('test/unit/lib/plugins/aws/package/compile/events/apiGateway/lib/hack/u
expect(untagResourceStub).to.have.been.calledOnce;
expect(untagResourceStub.args[0][0].tagKeys).to.deep.equal(['keytoremove']);
});

it('should deploys shouldStartNameWithService without apiName', async () => {
Copy link
Contributor

@pgrzesik pgrzesik Nov 8, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I only have one minor comment - in general, it's better to not override service for tests, as it's automatically generated - I see that here we need service for assertion so we can go this route instead:

const { serviceConfig, servicePath: serviceDir, updateConfig } = await fixtures.setup('apiGateway');
// Here we can get service from serviceConfig
await updateConfig(); // Here we can pass config ext content
await runServerless({cwd: serviceDir, ...}) // change fixture to cwd 

Here's a partial example on how fixtures are used along with runServerless:

const { servicePath: serviceDir, updateConfig } = await fixtures.setup('packageArtifact');

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should I also replace my const service = "..."; with serviceConfig.service?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, I don't remember exactly if under service there will be name or an object so you might need to check if serviceConfig.service.name won't be needed there

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a plain string, I've update the test.

Copy link
Contributor

@pgrzesik pgrzesik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, Ive missed one minor thing and we're good to go

@@ -150,7 +150,7 @@ async function resolveRestApiId() {
}
const apiName = apiGatewayResource
? apiGatewayResource.Properties.Name
: provider.apiName || `${this.options.stage}-${this.state.service.service}`;
: provider.apiName || provider.naming.getApiGatewayName();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've missed one thing here - provider.apiName is already resolved inside getApiGatewayName so let's simplify this and we're good to go

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

Copy link
Contributor

@pgrzesik pgrzesik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you @vicary, looks great 👍

@pgrzesik pgrzesik changed the title fixes #8720 fix(AWS API Gateway): Ensure shouldStartNameWithService support Nov 8, 2021
@pgrzesik pgrzesik merged commit e8c8d25 into serverless:master Nov 8, 2021
@SrushithR
Copy link

Hi @vicary @pgrzesik. Since the latest release (2.66.0), our deployments with serverless pro have started failing. The same stack without the serverless pro details deploys without any issues.

For now, I have downgraded the serverless package version to 2.65.0 and the deployments are working fine. Can you please help me with this?

@pgrzesik
Copy link
Contributor

pgrzesik commented Nov 10, 2021

Hello @SrushithR - could you please provide more details on how your deployments are failing? If you could share the error that you're experiencing that would be great

@vicary
Copy link
Contributor Author

vicary commented Nov 10, 2021

If this is reproducible and confirmed related, I'll make a regression test.

@pgrzesik
Copy link
Contributor

I think I've found the issue with the change - I'll prepare a PR with the fix and release shortly after it's accepted

@SrushithR
Copy link

SrushithR commented Nov 10, 2021

@pgrzesik Great. I have created an issue regarding the same - #10220

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants