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
feat(CLI Onboarding): Add deploy step #9536
Conversation
be72645
to
dc3ba46
Compare
lib/Serverless.js
Outdated
@@ -32,6 +32,7 @@ class Serverless { | |||
let configObject = config; | |||
configObject = configObject || {}; | |||
this._isInvokedByGlobalInstallation = Boolean(configObject._isInvokedByGlobalInstallation); | |||
this.isInvokedByInteractive = Boolean(configObject.isInvokedByInteractive); |
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 think we can avoid any internals hacking, by injecting the plugin as:
const serverless = new Serverless(...);
await serverless.init();
serverless.pluginManager.addPlugin(InteractiveDeployPluginConstructor);
Have you tried that?
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, changed to use this approach
lib/classes/CLI.js
Outdated
@@ -44,6 +44,12 @@ class CLI { | |||
this.log = function () {}; | |||
} | |||
|
|||
suppressLog() { |
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.
What exactly was the problem with overriding the process.stdout
via process-utils/override-stdout
?
Ideally we should not patch internals to achieve that
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.
Changed the approach to process-utils/override-stdout
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.
Ok, so I believe we no longer need this extension (?)
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.
Correct 👍
dc3ba46
to
22f40a4
Compare
@medikoo - I've changed the approach to patching stdout as you suggested. Could you take a look to confirm the direction is correct? If that's the case, I'll complete the PR with tests + full impl of
No 1. has the advantage of not depending on previous step, while no 2 saves some extra complexity/API calls to backend. As we only want to consider this |
22f40a4
to
75c4458
Compare
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.
Fetch providers again and see if the service has an explicit provider or if there's a default one
You've raised a good point, we didn't explore so far.
I think we simply need to ensure that AWS creds are loaded into environment when service is configured for dashboard, user is logged in to dashboard and there are provider credentials provided for service.
So I'd add following:
- At
service
step, if user had setup a dashboard ready service with org pre-configured (users may use custom templates), ensure creds are loaded from providers - At
dashboard-set-org
step ensure to load creds if for given org & service, creds are accessible - At
aws-credentials
step, if user created a provider, ensure to automatically load those creds into process
Having above, we should probably double confirm prior deploy that AWS credentials are loaded, and follow with deploy if we detect they're
lib/classes/CLI.js
Outdated
@@ -44,6 +44,12 @@ class CLI { | |||
this.log = function () {}; | |||
} | |||
|
|||
suppressLog() { |
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.
Ok, so I believe we no longer need this extension (?)
75c4458
to
841817f
Compare
Codecov Report
@@ Coverage Diff @@
## master #9536 +/- ##
==========================================
- Coverage 86.14% 86.11% -0.03%
==========================================
Files 324 326 +2
Lines 12331 12390 +59
==========================================
+ Hits 10622 10670 +48
- Misses 1709 1720 +11
Continue to review full report at Codecov.
|
841817f
to
1fd61de
Compare
@medikoo This is currently based on the PR with provider flow implementation to exclude changes, that's why there are no test runs reported, it will be run again after changing the base branch |
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.
@pgrzesik looks great! I have just few, mostly organization-wise concerns
lib/cli/interactive-setup/deploy.js
Outdated
process.stdout.write( | ||
`\n${chalk.green('Your project is live and available in ')}${chalk.white.bold( | ||
`./${serviceName}` | ||
)}\n` | ||
); | ||
process.stdout.write(`\n Run ${chalk.bold('serverless info')} in the project directory\n`); | ||
process.stdout.write(' View your endpoints and services\n'); | ||
process.stdout.write(`\n Open ${chalk.bold(getDashboardInteractUrl(dashboardPlugin))}\n`); | ||
process.stdout.write(' Invoke your functions and view logs in the dashboard\n'); | ||
process.stdout.write(`\n Run ${chalk.bold('serverless deploy')} in the project directory\n`); | ||
process.stdout.write( | ||
" Redeploy your service after you've updated your service code or configuration\n\n" | ||
); |
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.
nit: Maintainance wise it might be nicer to construct it with one process.stdout.write
but simply group messages in [].join("\n")
(also we may resort to template string, still then indentation could get quirky)
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.
Good call 👍
lib/plugins/deploy-interactive.js
Outdated
@@ -0,0 +1,36 @@ | |||
'use strict'; |
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'd keep this plugin in lib/cli/interactive-setup
as it serves only interactive deploy case, and it's a temporary hack, that at some point will be removed
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.
👍
lib/cli/interactive-setup/utils.js
Outdated
isUserLoggedIn: () => { | ||
if (process.env.SERVERLESS_ACCESS_KEY) { | ||
return true; | ||
} | ||
|
||
if (configUtils.getLoggedInUser()) { | ||
return true; | ||
} | ||
|
||
return false; | ||
}, | ||
doesServiceInstanceHaveLinkedProvider: async ({ configuration, options }) => { | ||
const region = resolveRegion({ configuration, options }); | ||
const stage = resolveStage({ configuration, options }); | ||
let result; | ||
try { | ||
result = await resolveProviderCredentials({ configuration, region, stage }); | ||
} catch (err) { | ||
if (err.statusCode && err.statusCode >= 500) { | ||
throw new ServerlessError( | ||
'Dashboard service is currently unavailable, please try again later', | ||
'DASHBOARD_UNAVAILABLE' | ||
); | ||
} | ||
throw err; | ||
} | ||
|
||
return Boolean(result); | ||
}, |
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.
Those utils feel to me as dashboard-plugin
utils, they're not specific to interactive CLI
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.
Do you suggest to move them to dashboard-plugin
then?
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 think it's a better fit, and I can imagine they will then become useful in other logic points
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.
As discussed previously, I've switched to use isAuthenticated
from the plugin but kept the other util here as we would still have to develop a similar wrapper for that functionality on Framework side.
@@ -61,6 +62,7 @@ | |||
"node-fetch": "^2.6.1", | |||
"object-hash": "^2.2.0", | |||
"path2": "^0.1.0", | |||
"process-utils": "^4.0.0", |
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.
Let's also remove it from devDependencies
1fd61de
to
a9953e3
Compare
8541b45
to
4c06d75
Compare
a9953e3
to
4e9f59b
Compare
4e9f59b
to
2768e9f
Compare
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 great 👍
Addresses: #9367