-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
proto_format: Optimize and cleanup #26496
Conversation
832bf86
to
ddbccbb
Compare
27b2529
to
391acc2
Compare
There is quite a bit that doesnt work with the proto formatting that is not really fixed by this PR - eg handling proto removal and addition. At least in my tests it breaks the same ways before/after Mostly what is required is better error handling, there are a lot of assumptions - eg that proto files are valid/well-formed - that dont necessarily stand up, which can have unpredictable consequences, and prevents the tool from being idempotent |
CC @envoyproxy/api-shepherds: Your approval is needed for changes made to |
a27d4cf
to
3d9da51
Compare
d66536a
to
d332976
Compare
i have tested a few scenarios random files on fs
unwanted proto or BUILD filesremoved in both cases incorrect
|
40c6bb3
to
739487f
Compare
@htuch i should stress that this is a step towards combining proto_format with |
# TODO(phlax): Move all of this code to `envoy.code.check` | ||
|
||
|
||
class Git(object): |
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.
by way of explanation - this is here to avoid a dependency on gitpython
or similar and to avoid the more expensive way of creating a python git repo and deriving the git hash/headers/diff from that (or shelling out and doing the same)
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.
Why avoid this dependency? I kind of feel there isn't a lot of value in us maintaining this code.
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.
its not just the dependency - it would add as much code and is less efficient - as discussed offline
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.
Ad discussed offline, I think I disagree with us maintaining our own git library and we should either find a more minimal version of what gitpython
does or create a separate repository for this and make it its own thing. I'm not including coverage of correctness here in the review as a result.
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.
ok - thanks for not blocking
its a minimal bit of code that will move asap, i believe its superuseful for when you want to create git appliable diffs without having to create repos to do it
ill move it asap
Signed-off-by: Ryan Northey <[email protected]>
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.
@phlax thanks and I think most of these make sense. Can I ask you to split this into a few PRs? In particular, can you move the super noisy mechanical trivial changes into their own? I prefer the philosophy that PRs should be long and trivial or small and non-trivial, but never long and non-trivial. Thanks.
Signed-off-by: Ryan Northey <[email protected]>
|
||
licenses(["notice"]) # Apache 2 | ||
|
||
# This tracks active development versions of protos. |
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 the biggest cleanup we'll see is to remove the versioning machinery, e.g. things like active / frozen distinction. We don't need to do this in this PR, but I think this will be a major win for simplification and performance.
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.
yep, agreed - i will do that as i go
Signed-off-by: Ryan Northey <[email protected]> Signed-off-by: River Phillips <[email protected]>
This PR:
BAZEL_VOLATILE_DIRTY
action env to bust local build stamps on tree changeThis uses stamped local build jobs to create a list of local api (git) hashes and a list of local modifications
The normalized api directory also has hashes created for comparison
normalized versions of any mismatched or modified files are downloaded and diffed to ensure the local versions match the normalized ones
this minimizes upload to bazel (only local diff files uploaded), RBE/bazel then processes the changes and gives back the minimum required for comparison (only normalized versions of changed files)
Commit Message:
Additional Description:
Risk Level:
Testing:
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]