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
Conversation
There was a problem hiding this 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}` |
There was a problem hiding this comment.
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.
@pgrzesik Thanks for the review. Sorry for not super familiar with the internal API yet, using I'll try writing a test with |
Perfect @vicary - let me know if you have any questions 💯 |
Codecov Report
@@ 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
Continue to review full report at Codecov.
|
@pgrzesik It was quite a trip to stub all the way down to |
There was a problem hiding this 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 () => { |
There was a problem hiding this comment.
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'); |
There was a problem hiding this comment.
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
?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this 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(); |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
There was a problem hiding this 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 👍
shouldStartNameWithService
support
Hi @vicary @pgrzesik. Since the latest release ( For now, I have downgraded the serverless package version to |
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 |
If this is reproducible and confirmed related, I'll make a regression test. |
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 |
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 customapiName
. 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)