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

feat(CLI Onboarding): Add deploy step #9536

Merged
merged 1 commit into from Jun 28, 2021
Merged

Conversation

pgrzesik
Copy link
Contributor

@pgrzesik pgrzesik commented Jun 1, 2021

Addresses: #9367

@pgrzesik pgrzesik added enhancement cat/cli-onboarding Interactive CLI onboarding labels Jun 1, 2021
@pgrzesik pgrzesik self-assigned this Jun 1, 2021
@pgrzesik pgrzesik marked this pull request as draft June 1, 2021 10:13
@@ -32,6 +32,7 @@ class Serverless {
let configObject = config;
configObject = configObject || {};
this._isInvokedByGlobalInstallation = Boolean(configObject._isInvokedByGlobalInstallation);
this.isInvokedByInteractive = Boolean(configObject.isInvokedByInteractive);
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 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?

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, changed to use this approach

@@ -44,6 +44,12 @@ class CLI {
this.log = function () {};
}

suppressLog() {
Copy link
Contributor

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

Copy link
Contributor Author

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

Copy link
Contributor

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 (?)

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 👍

lib/cli/interactive-setup/deploy.js Outdated Show resolved Hide resolved
lib/plugins/deploy-interactive.js Outdated Show resolved Hide resolved
@pgrzesik
Copy link
Contributor Author

pgrzesik commented Jun 2, 2021

@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 isApplicable. As for that, I have a question about the approach to take. I'm a bit torn as we have two potential approaches:

  1. Fetch providers again and see if the service has an explicit provider or if there's a default one
  2. Expand history in context to track that provider was succesfully setup as a part of aws-credentials step

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 deploy step for new services, I'm leaning towards second approach, but I'd love to hear your opinion on that.

@pgrzesik pgrzesik requested a review from medikoo June 2, 2021 14:25
@pgrzesik pgrzesik changed the title feat(CLI Onboarding): Add deploy step [WIP] feat(CLI Onboarding): Add deploy step Jun 4, 2021
@pgrzesik pgrzesik marked this pull request as ready for review June 4, 2021 14:25
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.

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

@@ -44,6 +44,12 @@ class CLI {
this.log = function () {};
}

suppressLog() {
Copy link
Contributor

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 (?)

lib/cli/interactive-setup/aws-credentials.js Show resolved Hide resolved
@pgrzesik pgrzesik marked this pull request as draft June 7, 2021 19:14
@codecov
Copy link

codecov bot commented Jun 9, 2021

Codecov Report

Merging #9536 (97d9585) into master (feb0421) will decrease coverage by 0.02%.
The diff coverage is 81.92%.

❗ Current head 97d9585 differs from pull request most recent head 2768e9f. Consider uploading reports for the commit 2768e9f to get more accurate results
Impacted file tree graph

@@            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     
Impacted Files Coverage Δ
lib/cli/interactive-setup/index.js 100.00% <ø> (ø)
...ib/cli/interactive-setup/deploy-progress-plugin.js 21.42% <21.42%> (ø)
lib/cli/interactive-setup/utils.js 93.75% <91.66%> (-6.25%) ⬇️
lib/cli/interactive-setup/deploy.js 93.75% <93.75%> (ø)
lib/cli/interactive-setup/aws-credentials.js 88.88% <100.00%> (+1.25%) ⬆️
lib/cli/interactive-setup/service.js 100.00% <100.00%> (ø)

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 feb0421...2768e9f. Read the comment docs.

@pgrzesik pgrzesik marked this pull request as ready for review June 9, 2021 09:31
@pgrzesik pgrzesik changed the base branch from master to support-provider-setup-flow June 9, 2021 09:31
@pgrzesik pgrzesik requested a review from medikoo June 9, 2021 09:38
@pgrzesik
Copy link
Contributor Author

pgrzesik commented Jun 9, 2021

@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

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.

@pgrzesik looks great! I have just few, mostly organization-wise concerns

Comment on lines 19 to 32
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"
);
Copy link
Contributor

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)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good call 👍

lib/cli/interactive-setup/deploy.js Show resolved Hide resolved
@@ -0,0 +1,36 @@
'use strict';
Copy link
Contributor

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

👍

Comment on lines 21 to 37
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);
},
Copy link
Contributor

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

Copy link
Contributor Author

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?

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 think it's a better fit, and I can imagine they will then become useful in other logic points

Copy link
Contributor Author

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",
Copy link
Contributor

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

@pgrzesik pgrzesik force-pushed the support-provider-setup-flow branch from 8541b45 to 4c06d75 Compare June 28, 2021 09:25
Base automatically changed from support-provider-setup-flow to master June 28, 2021 09:54
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.

Looks great 👍

@pgrzesik pgrzesik merged commit 28a06a0 into master Jun 28, 2021
@pgrzesik pgrzesik deleted the add-deploy-to-interactive branch June 28, 2021 11:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cat/cli-onboarding Interactive CLI onboarding enhancement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants