-
Notifications
You must be signed in to change notification settings - Fork 466
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
Revert "build: rework node resolution" #2124
Conversation
This reverts commit 616fb3e. Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
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.
Note ^
"platform":"darwin/arm64/v8"
.
Hum platforms.DefaultSpec()
looks to be passed where it should be inferred from the node where the build occurs.
We also should look at this patch critically from readability. It isn't entirely obvious to me why there is a second map with same keys
driversSolveOpts
making it hard to track what is actually going on.
👍
Instead of reverting, can this not just be removed?
I think this is significantly easier to understand than the previous iteration - this was part of the driverPair.so, and was being set as part of the call to Build (and wasn't actually being accessed anywhere else outside of that), which mixed concerns into a single strict whose general purpose was unclear. I'd personally prefer a fix instead of a full revert, since I'd like to keep the changes to the ordered resolution (and the tests which verify how the platform resolution actually works), but since I'm on holiday I'm not actually able to write a fix for that right now, so won't block on a revert. |
I don't think @crazy-max is referring to a specific line. This is a side-effect of the new driver resolver where it seems to set platforms (for the build request) in cases where they should not be set (because the user did not set them). I don't know where the
Maybe driverPair is not a best name but holding the pointer to specific implementation and specific request that have strict 1-1 mapping together in the same struct and passing them around together looks much safer than indexing them in two separate maps and passing multiple maps around where implementations need to do multiple string based lookups and hope that everything is synchronized and there isn't any mismatch. |
nodes = append(nodes, &resolvedNode{ | ||
resolver: r, | ||
driverIndex: idx, | ||
platforms: []specs.Platform{ps[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.
I think this is the line causing the DefaultSpec issue. It should not be set here if the default case with no specified platforms from above was bit.
I don't think they were being passed around together. They were only being set and accessed in |
Fair enough, I can see the argument for putting the solve opt back into the struct - the original PR already does the work to rename driverPair to resolvedNode, so it would just be a matter of updating that. |
We need to do something with this. The master branch is completely broken in darwin atm for example. |
This reverts commit 616fb3e.
#2115 #1966
Regression report:
The PR adds an invalid platform in this case, when user specified none. In
SolveOpt
:Note ^
"platform":"darwin/arm64/v8"
.We also should look at this patch critically from readability. It isn't entirely obvious to me why there is a second map with same keys
driversSolveOpts
making it hard to track what is actually going on.