Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Correct signing order for macOS bundles #1910
Correct signing order for macOS bundles #1910
Changes from 5 commits
717799b
0647fa7
f03a8ae
3b2ca82
cb61a72
3ec36b3
f20ff4b
ab7bb5f
e2fc32f
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
But it doesn't guarantee that subfolders and files in the same folder are put into separate groups. For example, if there was no Helpers directory, the group separation would be:
Because the last two paths have the same parent, they would be signed in parallel.
Possible solution: make the key for both sorting and grouping be
(path.parent, path.is_dir())
, and sort withreverse=True
. Those two elements map directly onto the two requirements stated in the comment.If the grouping was factored out into a utility function, it could be covered by a test.
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 catch - I hadn't considered that although the sort order will put the directory first, if they're grouped together parallelism won't guarantee their signed in that order.
I've modified the grouping as you've described (well - close - the sorting already puts directories before files, so we just need a different grouping key, not a full reverse sort order).
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.
WIth
reverse=True
, I think the sorting and grouping key can both be(path.parent, path.is_dir())
, and all the complexity ofsorted_depth_first
can be removed.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.
The ordering within the group shouldn't matter, but to make the build a bit more reproducible (and pass the tests), it would also be a good idea to sort within each group by the full paths.
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.
The key can't be exactly the same, because the sorting process needs to sort the actual files, whereas the grouping needs to sort on the containers of the files. So - we need to have a different key; the three-element key gives the sort order that matches a normal directory listings, so in any debug log it's going to be marginally less confusing. The 3-element key also matches the "complexity" of the actual search - sorting by "depth, then by directory vs file, then by filename" is literally what the algorithm is sorting on, rather than relying on a subtle edge effect of reverse interacting with the boolean value of
is_dir()
.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, so we can sort the whole list by
key=(path.parent, path.is_dir()), reverse=True
, then group by the same key, then sort each group bypath
. That's still much easier to understand than the current version ofsorted_depth_first
, which creates keys which are lists of tuples.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.
Unless the file sorting contains the actual path in the key, the ordering of files/folders inside any given group will be at least partially unpredictable. This won't matter to the signing order, but it makes testing a little harder because we can't completely guarantee the order of the output.
It also seems a little silly to me have a
sort
method that doesn't fully sort. Plus, we're already sorting, so requiring a second pass of sorting (in the test harness, and potentially in the usage of the final groups) seems a little silly.However, I can't argue that the simple tuple is much easier to understand than the list of tuples, even if the resulting order isn't quite a "lexically pleasing" as the more complex option; and we can fix the filename sorting by adding the actual path to the initial sort key (using the simpler 2 part key for the grouping key).