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

Built in integration of serverless enterprise #6074

Merged
merged 34 commits into from
May 28, 2019
Merged

Built in integration of serverless enterprise #6074

merged 34 commits into from
May 28, 2019

Conversation

dschep
Copy link
Contributor

@dschep dschep commented May 1, 2019

What did you implement:

PLAT-916

How did you implement it:

Added SFE plugin as a dependency and automatically load it, explicitly from sls's node_modules to avoid issues with global installation.

How can we verify it:

npm i -g serverless/serverless#plat-916

if you have logged into SFE, first remove those details from or remove the ~/.serverlessrc file entirely. Then use sls to do some deploys, you should get the ad about SFE on deploys.

then run sls login and deploy again, you should get warnings about configuring app&tenant.

configure app&tenant and deploy again. should now be using SFE!

Todos:

  • Write tests
  • Write documentation
  • Fix linting errors
  • Make sure code coverage hasn't dropped
  • Provide verification config / commands / resources
  • Enable "Allow edits from maintainers" for this PR
  • Update the messages below

Is this ready for review?: YES
Is it a breaking change?: NO

Copy link
Contributor

@pmuens pmuens left a comment

Choose a reason for hiding this comment

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

Looks good so far @dschep 👍

Just added one comment regarding path joining...

@pmuens pmuens changed the title built in integration of serverless enterprise Built in integration of serverless enterprise May 2, 2019
@dschep dschep marked this pull request as ready for review May 6, 2019 13:07
@dschep dschep requested review from pmuens, medikoo and eahefnawy May 14, 2019 18:04
.travis.yml Outdated
- node_js: '4.4'
env: SLS_IGNORE_WARNING=*
- node_js: '5.11'
env: SLS_IGNORE_WARNING=*
Copy link
Contributor

Choose a reason for hiding this comment

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

I would leave it to #6077 (still I guess it was probably done to have CI pass)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, either that has to be merged first or I have to do it here too.

.travis.yml Outdated
@@ -42,6 +38,7 @@ matrix:
- LINTING=true
sudo: false
install:
- travis_retry npm install -g npm
Copy link
Contributor

Choose a reason for hiding this comment

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

Why? (line below it's followed by npm install)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

npm install doesn't upgrade npm and some dep of enterprise plugin requires a new version of npm to install correctly.

Copy link
Contributor

Choose a reason for hiding this comment

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

Isn't that related purely to npm version that comes with Node.js v4? (of which testing we drop)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

i'll try removing it but i think other versions needed update dnpm too

Copy link
Contributor

Choose a reason for hiding this comment

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

I think once testing of v4 and v5 is dropped, it should not be an issue (and better to drop it, as it adds time to CI build, and installs npm version not yet "approved" by Node.js)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

this already drops node 4&5, it's still needed on node 6

@@ -148,7 +152,27 @@ class PluginManager {
if (pluginsObject.localPath) {
module.paths.unshift(pluginsObject.localPath);
}
this.loadPlugins(pluginsObject.modules);
this.loadPlugins(pluginsObject.modules
.filter(name => name !== '@serverless/enterprise-plugin'));
Copy link
Contributor

Choose a reason for hiding this comment

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

Is it just to prevent accidental load of enterprise plugin if user lists @serverless/enterprise-plugin in serverless.yml plugins section?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yes.

Copy link
Contributor

Choose a reason for hiding this comment

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

Is it because we don't want to load plugins twice? In that case we already have (or had) that logic in the plugin manager.

Maybe the logic related to the @serverless/enterprise-plugin is an edge case though...

Copy link
Contributor

Choose a reason for hiding this comment

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

It's probably good to treat it separately here, but I guess it'll be good to show some warning to the user, that @serverless/enterprise-plugin should not be listed as plugin (and carry on as normal).

That way we don't leave an impression that such configuration of a plugin is expected.

@dschep
Copy link
Contributor Author

dschep commented May 22, 2019

Is it because we don't want to load plugins twice? In that case we already have (or had) that logic in the plugin manager.

Maybe the logic related to the @serverless/enterprise-plugin is an edge case though...

@pmuens i can't seem to reply directly. but yes, we don't want to throw a warning about the duplicate either.

@dschep
Copy link
Contributor Author

dschep commented May 22, 2019

@medikoo it is intentional to load after other plugins. This is because it has to be after plugins like webpack or other transpilation tools.

@dschep dschep requested a review from medikoo May 23, 2019 13:16
Copy link
Contributor

@medikoo medikoo left a comment

Choose a reason for hiding this comment

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

It needs conflicts to be resolved

@dschep dschep requested review from medikoo and pmuens and removed request for medikoo May 23, 2019 16:41
.travis.yml Outdated
@@ -36,6 +36,7 @@ matrix:
env: SLS_IGNORE_WARNING=*
sudo: false
install:
- "[ $TRAVIS_OS_NAME = windows ] || travis_retry npm install -g npm"
Copy link
Contributor

Choose a reason for hiding this comment

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

Why is it needed just in Windows case?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

npm i -g npm doesn't work on windows travis builders bc apparently the user doesn't have enough permission, and it's not necessary bc the windows build has a new enough node/npm that it doesn't need to be upgraded.

Copy link
Contributor

Choose a reason for hiding this comment

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

As we clarified on Slack, it's about invalid listing of zlib in package.json. it's old module that doesn't compile on new node.js versions (recent ones totally ignore it), and crashes v6.

zlib is a Node.js native module since v0.12.

Removing it from package.json will fix it

@@ -148,7 +152,27 @@ class PluginManager {
if (pluginsObject.localPath) {
module.paths.unshift(pluginsObject.localPath);
}
this.loadPlugins(pluginsObject.modules);
this.loadPlugins(pluginsObject.modules
.filter(name => name !== '@serverless/enterprise-plugin'));
Copy link
Contributor

Choose a reason for hiding this comment

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

It's probably good to treat it separately here, but I guess it'll be good to show some warning to the user, that @serverless/enterprise-plugin should not be listed as plugin (and carry on as normal).

That way we don't leave an impression that such configuration of a plugin is expected.

@@ -1,5 +1,7 @@
service:
name: aws-alexa-typescript
#app: your-app-name
Copy link
Contributor

Choose a reason for hiding this comment

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

I guess it's about credentials to Enterprise account. Wouldn't it be better to accompany it with comment as e.g.:

# A credentials to eventual Serverless Enterprise account
# see https://serverless.com/acceleration/ for more details

Otherwise it gives no hint what those settings are about

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 not a credential, but yeah, i'll check with product what copy they'd like

Copy link
Contributor

Choose a reason for hiding this comment

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

Pretty sure it is, but is this only required for our AWS templates right now?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Correct. SFE only supports AWS.

@pmuens pmuens added this to the 1.44.0 milestone May 24, 2019
Copy link
Contributor

@pmuens pmuens left a comment

Choose a reason for hiding this comment

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

LGTM from a code perspective :shipit:

Just added 2 minor questions.

if (config.getGlobalConfig().enterpriseDisabled) {
return;
}
module.paths.unshift(path.join(__dirname, '../../node_modules'));
Copy link
Contributor

Choose a reason for hiding this comment

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

I might've asked this before, but this will work on Windows, since path.join is able to turn / into \, correct?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

oh right.. i tested this when i did it the other way (hacking it into a relative import). I think this'll work, but I'll boot up my window sbox to double check

Copy link
Contributor Author

Choose a reason for hiding this comment

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

works!

@@ -1,5 +1,7 @@
service:
name: aws-alexa-typescript
#app: your-app-name
Copy link
Contributor

Choose a reason for hiding this comment

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

Pretty sure it is, but is this only required for our AWS templates right now?

@dschep dschep merged commit 224669d into master May 28, 2019
@medikoo medikoo deleted the plat-916 branch December 10, 2019 10:47
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.

3 participants