Skip to content

feat: allow initializing workloads during copilot deploy#5168

Merged
mergify[bot] merged 22 commits intoaws:mainlinefrom
bvtujo:chore/init-deploy-logic
Aug 23, 2023
Merged

feat: allow initializing workloads during copilot deploy#5168
mergify[bot] merged 22 commits intoaws:mainlinefrom
bvtujo:chore/init-deploy-logic

Conversation

@bvtujo
Copy link
Copy Markdown
Contributor

@bvtujo bvtujo commented Aug 8, 2023

This is stacked on top of a couple of PRs (like 5128 and 5139). The diff should get smaller over time as those are merged.

Adds a new method to initialize which skips manifest writing.

I think the ideal scenario here is actually to use an initializer option on the workload initializer struct, but I wanted to get this out quickly rather than doing another big 300-line refactor if possible. Happy to do this after release; i actually have started the work.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the Apache 2.0 License.

@bvtujo bvtujo requested a review from a team as a code owner August 8, 2023 18:40
@bvtujo bvtujo requested review from Lou1415926 and removed request for a team August 8, 2023 18:40
Comment thread internal/pkg/cli/deploy.go Outdated

// If init-wkld and no-init-wkld flags aren't set, prompt customer to initialize.
if !o.yesInitWkld {
o.yesInitWkld, err = o.prompt.Confirm(fmt.Sprintf("Found manifest for uninitialized %s %q. Initialize it?", workloadType, o.name), "This workload will be initialized, then deployed.", prompt.WithConfirmFinalMessage())
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

❤️

Comment thread internal/pkg/cli/flag.go Outdated
Comment on lines +37 to +38
yesInitWorkloadFlag = "init-wkld"
noInitWorkloadFlag = "no-init-wkld"
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Just a thought. Should this be a bool instead? I understand wanting consistency with the other flags (deploy/no-deploy). 🤷🏼

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

You don't actually get the right amount of granularity if it's just a bool.

For example, if we just use init-wkld and the flag is un-specified, it's false. Then do you prompt for initialization, or do you assume the user's intent is not to init the workload and error out? It leads to problems where there's no way to force the command to exit when the intent is not to init the workload if it doesn't exist, or there's no way to display a prompt when the intent is ambiguous. Perhaps a pointer to a bool would do it, but I don't think there's a way of specifying a bool flag like --init=false in cobra.

Long winded way of saying that as far as I can tell, the best way to specify choices like this where we want to prompt by default but allow customers to specify either a positive or a negative is to use two mutually exclusive bool flags.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

It sounds to be very similar to

if cmd.Flags().Changed(yesFlag) {
🤔

Comment thread internal/pkg/cli/init.go
Comment thread internal/pkg/initialize/workload.go Outdated
Copy link
Copy Markdown
Contributor

@CaptainCarpensir CaptainCarpensir left a comment

Choose a reason for hiding this comment

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

Looks cool 👀
Couple nits

@github-actions
Copy link
Copy Markdown

github-actions Bot commented Aug 18, 2023

🍕 Here are the new binary sizes!

Name New size (kiB) size (kiB) Delta (%)
macOS (amd) 51632 51488 +0.28
macOS (arm) 51844 51684 +0.31
linux (amd) 45452 45324 +0.28
linux (arm) 43716 43588 +0.29
windows (amd) 42260 42144 +0.28

@codecov-commenter
Copy link
Copy Markdown

codecov-commenter commented Aug 18, 2023

Codecov Report

Merging #5168 (9b35f0b) into mainline (86efee6) will decrease coverage by 0.01%.
Report is 1 commits behind head on mainline.
The diff coverage is 57.14%.

@@             Coverage Diff              @@
##           mainline    #5168      +/-   ##
============================================
- Coverage     69.52%   69.51%   -0.01%     
============================================
  Files           295      295              
  Lines         43897    43988      +91     
  Branches        285      285              
============================================
+ Hits          30518    30579      +61     
- Misses        11889    11913      +24     
- Partials       1490     1496       +6     
Files Changed Coverage Δ
internal/pkg/cli/deploy.go 36.08% <49.23%> (+8.74%) ⬆️
internal/pkg/cli/init.go 25.59% <52.63%> (+1.75%) ⬆️
internal/pkg/initialize/workload.go 78.24% <100.00%> (+1.22%) ⬆️

... and 4 files with indirect coverage changes

Copy link
Copy Markdown
Contributor

@dannyrandall dannyrandall left a comment

Choose a reason for hiding this comment

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

i'm curious what the difference is between svc init --deploy and svc deploy after these changes?

Comment on lines +257 to +262
if cmd.Flags().Changed(yesInitWorkloadFlag) {
opts.yesInitWkld = aws.Bool(false)
if initWorkload {
opts.yesInitWkld = aws.Bool(true)
}
}
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

why this? instead of just setting vars.yesInitWkld down below??

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

ah i think sort of answered this below, but +1 to @iamhopaul123's question there - it seems like this is another way of doing the same thing?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I hadn't seen this way of using a pointer, but using this construct instead of two mutually exclusive flags actually simplifies the logic in a pleasant way. This way the behavior is clear and the user is only prompted if they don't specify the flag one way or another via --init-wkld=false or --init-wkld.

@bvtujo
Copy link
Copy Markdown
Contributor Author

bvtujo commented Aug 21, 2023

This shouldn't affect svc deploy at all; I tried to scope these changes only to deploy to provide a more guided experience which can also be used in CI.

When a customer does copilot init --deploy we do the following:

  1. prompt them to initialize a service
  2. prompt them to initialize a test environment with limited customization
  3. deploy the environment
  4. deploy the service

With this change to copilot deploy, we do the following:

  1. Check for local manifests and include them in validation
  2. if the service the customer selects via flags or prompting doesn't exist, prompt the customer to initialize it using info gleaned from the local manifest
  3. deploy the service

My next PR will do the same for local environment manifests:

  1. prompt the customer to initialize the environment if a manifest exists and it isn't yet initted
  2. optionally deploy the environment before deploying the service.

Copy link
Copy Markdown
Contributor

@iamhopaul123 iamhopaul123 left a comment

Choose a reason for hiding this comment

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

LGTM overall! just one question.

Comment thread internal/pkg/cli/flag.go Outdated
Comment thread internal/pkg/cli/init.go Outdated
Comment thread internal/pkg/cli/flag.go Outdated
Comment thread internal/pkg/cli/flag.go Outdated
Comment thread internal/pkg/cli/flag.go Outdated
@dannyrandall dannyrandall added the do-not-merge Pull requests that mergify shouldn't merge until the requester allows it. label Aug 22, 2023
@bvtujo bvtujo removed the do-not-merge Pull requests that mergify shouldn't merge until the requester allows it. label Aug 23, 2023
@mergify mergify Bot merged commit 26c79c9 into aws:mainline Aug 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Archived in project

Development

Successfully merging this pull request may close these issues.

7 participants