-
Notifications
You must be signed in to change notification settings - Fork 23
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
REALMC-9363 - Removed client-side transpilation. #178
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.
Good start! 💪
Still WIP just want to see how it runs without |
btw you can run evergreen patches through this command line tool as well. |
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 you'll need to make sure we're updating tests for app diff
and push
here as well
let me know if you have any questions/thoughts about my comments here, would be happy to discuss anything further.
i am incredibly excited to see we can remove all things transpiler-related from this codebase though! nice work so far
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.
Just some things I am not so sure about.
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.
lookin good here, just have another batch of comments/questions for you. really nice turnaround on a lot of this stuff!
internal/cloud/realm/client.go
Outdated
@@ -30,6 +30,7 @@ type Client interface { | |||
ImportDependencies(groupID, appID, uploadPath string) error | |||
Diff(groupID, appID string, appData interface{}) ([]string, error) | |||
DiffDependencies(groupID, appID, uploadPath string) (DependenciesDiff, error) | |||
DependenciesInstallation(groupID, appID string) (DependenciesInstallation, error) |
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.
thoughts on just naming this DependenciesStatus
(or DependenciesInstallationStatus
)? the latter is a bit wordy, but I think it might help convey that this client method is getting status information... I don't have a strong opinion on this one, I'm just having a hard time reasoning what an "installation" means
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 about DependenciesImportStatus
or DependenciesInstallStatus
? DependenciesImportStatus
seems to make most sense to me considering this is only being used for ImportDependencies
right now and installation is technically related to the import as a whole? It's a bit weird how the process essentially starts as an import and ends as an install. @arahmanan
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.
my one caution here would be that we shouldn't name the client method based on how its used, we should name it for what it does.
I finally got up to speed took a look over on the baas
side... I would vote one of the following:
- keep it as
DependenciesInstallation
... I didn't realize that's how we referred to thestruct
in the backend, I can figure out how to reason what an installation means eventually - use
DependenciesStatus
since that's what the API handler is called (getDependenciesStatus
)
I think ultimately I like the latter, although then it introduces a stutter with the Status
field (which could additionally be renamed to State
or Type
while keeping the json
mapping the same "status"
)
at the very least, I think this encourages us to remove the type DependencyStatus string
as its overloading more of these words, and really doesn't add anything that a simple string
couldn't do
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.
on a different note I guess simply naming it DependenciesStatus
makes sense considering it's a request to the dependencies/status
endpoint so seems most fitting for 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.
I don't have a strong opinion on this. I am also in favor of calling this function DependenciesStatus
. I might also rename that in baas
if it leads to confusion.
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.
Hopefully this addresses many of the issues so far.
internal/commands/push/command.go
Outdated
@@ -198,7 +198,35 @@ func (cmd *Command) Handler(profile *user.Profile, ui terminal.UI, clients cli.C | |||
if err := clients.Realm.ImportDependencies(appRemote.GroupID, appRemote.AppID, uploadPathDependencies); err != nil { | |||
return err | |||
} | |||
ui.Print(terminal.NewTextLog("Uploaded dependencies archive")) | |||
|
|||
ui.Print(terminal.NewTextLog("Uploaded dependencies")) |
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.
Is this message necessary? If so, I thought it would be good to make it more consistent with the "Installed dependencies" message that should occur after it.
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 does seem like it can go away now... it previously existed to mark the completion of this block, which as you allude to is now done with the "Installed dependencies" message below
I think the key here is we want to make sure this behaves similarly (read: prints the same amount of logs) as the hosting and/or reset cdn blocks do below (which from the looks of it appears to be the case)
Have you tested this locally yet? I'm guessing there's a test case below that can also confirm this...
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, as you saw below in the tests it ends up being 2 dependencies-related messages in the tests so I will remove it.
|
||
// wait for dependencies to finish installation | ||
var currentStatus realm.DependenciesStatus | ||
for i := 0; i < 50; i++ { |
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.
in my computer it usually takes around <15 runs but I imagine with all sorts of delays and all, 50
seems to be a good balance between making sure it isn't flaky but also not running for too long; could be lowered.
|
||
paramFile = "file" | ||
) | ||
|
||
// DependenciesStatus is used to get information from a dependencies status request | ||
type DependenciesStatus struct { | ||
State string `json:"status"` |
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 this may be the best way to avoid stutter but I can see how the idea of a State of Status is a bit odd.
|
||
// set of known dependencies status states | ||
const ( | ||
DependenciesStateCreated = "created" |
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 updated these to make them more related to the status.State
as opposed to the status
itself.
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.
last few things from me, but this is lookin 🔥
internal/commands/push/command.go
Outdated
@@ -198,7 +198,35 @@ func (cmd *Command) Handler(profile *user.Profile, ui terminal.UI, clients cli.C | |||
if err := clients.Realm.ImportDependencies(appRemote.GroupID, appRemote.AppID, uploadPathDependencies); err != nil { | |||
return err | |||
} | |||
ui.Print(terminal.NewTextLog("Uploaded dependencies archive")) | |||
|
|||
ui.Print(terminal.NewTextLog("Uploaded dependencies")) |
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 does seem like it can go away now... it previously existed to mark the completion of this block, which as you allude to is now done with the "Installed dependencies" message below
I think the key here is we want to make sure this behaves similarly (read: prints the same amount of logs) as the hosting and/or reset cdn blocks do below (which from the looks of it appears to be the case)
Have you tested this locally yet? I'm guessing there's a test case below that can also confirm this...
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.
just one final question I'd like for you to answer via local testing, lmk if you want any help in setting that up
otherwise this looks terrific, really nice work here
🆒 beans
if err != nil { | ||
return err | ||
} | ||
s.Suffix = fmt.Sprintf(" Installing dependencies: %s...", status.Message) |
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.
[question] maybe you can try to test this out (either by running the command and watching closely or mocking the realm client to suit your needs), but do we experience any "flicker" on this spinner/message when it's being set on every for loop iteration?
i ask b/c if so, then maybe we only want to be calling s.Suffix = ...
if/when status.Message
changes (which would then force us to remove the var err error
declaration and use something like s, err := clients.Realm.DependenciesStatus(...)
so we can have reference to both past and current statuses
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 did not see any flicker when doing my testing so I don't think it's a problem. Unrelated to this, but I did notice a case of (spinner) Installing dependencies: ...
when testing commands but this is because of the mock functions not providing any status messages during some tests. I could add status messages to the mock functions if this matters for tests. Previously when I ran tests with an actual server and a spinner it'd always have some sort of status message i.e. processing
so for the CLI as a whole this is not a problem.
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.
Awesome, and I wouldn't both with crafting messages for the tests, that text doesn't persist anyways (we don't assert on it)
I'd say all of this is good to go then!
POST
endpoint with the newPUT
endpoint.