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

Runtime refactor #3348

Merged
merged 173 commits into from
Jul 15, 2024
Merged

Runtime refactor #3348

merged 173 commits into from
Jul 15, 2024

Conversation

Naatan
Copy link
Member

@Naatan Naatan commented Jun 7, 2024

No description provided.

@Naatan Naatan requested a review from MDrakos June 28, 2024 18:45
Copy link
Member

@MDrakos MDrakos left a comment

Choose a reason for hiding this comment

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

With a PR this big it's easy to get lost in the weeds. I tried to take a step back and look at how the new code is structured and how it is used throughout our codebase. From that standpoint this PR is a huge success. The new runtime code is easy to read and understand and it's uses all make sense to me and are an improvement over what we had before. Great job!

There are a few more minor comments and things to consider before we land this.

if err != nil {
wp.errorsOccurred = true
}
wp.errors <- err
Copy link
Member

Choose a reason for hiding this comment

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

Is it possible that we are writing nil to the error channel for every invocation of fn? If we move this inside the err != nil block can be omit the continue on line 80?

Copy link
Member Author

Choose a reason for hiding this comment

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

I think you're right! 👍

@@ -81,3 +81,7 @@ func IsNetworkingError(err error) bool {
}
return false
}

func RuntimeDisabled() bool {
return os.Getenv(constants.DisableRuntime) == "true"
Copy link
Member

Choose a reason for hiding this comment

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

May want to use strings.EqualFold here

Copy link
Member Author

Choose a reason for hiding this comment

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

Gonna leave it as it's inconsistent with the logic of the rest of that file. Making these case insensitive doesn't seem to have much value imo.

func ExecutablePaths(env map[string]string) ([]string, error) {
// Retrieve artifact binary directory
var bins []string
if p, ok := env["PATH"]; ok {
Copy link
Member

Choose a reason for hiding this comment

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

nit: can return early here if PATH isn't set.

@@ -30,7 +30,7 @@ func (rt *RoundTripper) RoundTrip(req *http.Request) (*http.Response, error) {

resp, err := rt.client.Do(retryableReq)
if err != nil && resp != nil && resp.StatusCode == http.StatusForbidden && strings.EqualFold(resp.Header.Get("server"), "cloudfront") {
return nil, platform.NewCountryBlockedError()
return nil, api_errors.NewCountryBlockedError()
Copy link
Member

Choose a reason for hiding this comment

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

There is no right or wrong here but I'm only used to seeing underscores for test and build files. I believe we've avoided snake case for package names and other tokens in Go.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, a while ago I had brought this up in stand, but it probably bears repeating. Our codebase has gotten to such a large size that following idiomatic Go naming conventions gives us too many collisions. At which point we're using aliases where needed, and those aren't usually very consistent.

Given the givens I'd rather have underscores and non-colliding package names than no underscores and collision galore.

Imo the naming conventions only make sense on projects that are Go libraries, once you start working on a Go application it very quickly stops making sense.

Copy link
Member

Choose a reason for hiding this comment

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

I agree that the aliases were getting a bit out of hand but I'm still not seeing how underscores solve this problem. Could api_errors not be apiErrors or does go complain about that as well?

Either way this should be considered a nit as I don't want to hold the PR up. I just wanted to flag us introducing something that we have called out in the past for both file and package names.

Copy link
Member Author

Choose a reason for hiding this comment

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

Oh sure, yeah it could be. Especially now that we're ignoring idiomatic Go in this context anyway. I just used underscore since that at least partly aligns with Go's standard (eg. pkg_test.go), plus it sidesteps the whole case sensitive filesystems issue.

if a, ok := p.buildsExpected[id]; ok {
name = a.NameAndVersion()
}
case StepDownload:
Copy link
Member

Choose a reason for hiding this comment

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

Should this also cover StepUnpack?

Copy link
Member Author

Choose a reason for hiding this comment

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

Nice catch

return locale.NewInputError("refresh_runtime_uptodate")
}

r.prime.SetProject(proj)
Copy link
Member

Choose a reason for hiding this comment

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

I don't believe proj is changing between here and where SetProject is called on line 73. Is this call necessary?

Comment on lines +50 to +62
if err := os.MkdirAll(dest, 0755); err != nil {
return errs.Wrap(err, "could not create directory %s", dest)
}
entries, err := os.ReadDir(src)
if err != nil {
return errs.Wrap(err, "could not read directory %s", src)
}
for _, entry := range entries {
if err := Link(filepath.Join(src, entry.Name()), filepath.Join(dest, entry.Name())); err != nil {
return errs.Wrap(err, "sub link failed")
}
}
return nil
Copy link
Member

Choose a reason for hiding this comment

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

nit: could be linkDir function similar to linkFile below.

Copy link
Member Author

Choose a reason for hiding this comment

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

There is no linkDir function? That's basically what Link() is.

Comment on lines +72 to +75
if err := linkFile(src, dest); err != nil {
return errs.Wrap(err, "could not link %s to %s", src, dest)
}
return nil
Copy link
Member

Choose a reason for hiding this comment

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

nit:

Suggested change
if err := linkFile(src, dest); err != nil {
return errs.Wrap(err, "could not link %s to %s", src, dest)
}
return nil
return linkFile(src, dest)

But then you may have to adjust the error in the caller.

Copy link
Member Author

Choose a reason for hiding this comment

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

That's an anti-pattern; we would loose the context of where linkFile encountered an error. Of course it's in this case pretty self-explanatory, but we don't know how this code might evolve.

result = strfmt.UUID(id.ID)
}
return result, nil
func (b *BuildPlan) RecipeID() strfmt.UUID {
Copy link
Member

Choose a reason for hiding this comment

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

Perhaps this function should also be called LegacyRecipeID

Comment on lines 74 to 76
func FilterNeedsBuild() FilterArtifact {
return func(a *Artifact) bool {
return a.Status != types.ArtifactSucceeded
Copy link
Member

Choose a reason for hiding this comment

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

Is this true? A failed or skipped artifact does not need to be built and it won't be in the future.

Copy link
Member Author

Choose a reason for hiding this comment

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

I've renamed it to FilterNotBuild(), because the code using this does in fact want artifacts that failed.

@Naatan Naatan requested a review from MDrakos July 15, 2024 18:39
@Naatan Naatan merged commit 8727a44 into version/0-46-0-RC1 Jul 15, 2024
4 of 7 checks passed
@Naatan Naatan deleted the DX-2721 branch July 15, 2024 22:44
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.

2 participants