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

Test that the stdlib rule does not insert build ids in archives #1454

Merged
merged 2 commits into from
Apr 19, 2018

Conversation

jayconrod
Copy link
Contributor

Related #1440

@jayconrod
Copy link
Contributor Author

cc @steeve


def _stdlib_files_impl(ctx):
files = ctx.attr._stdlib[GoSource].stdlib.files
runfiles = ctx.runfiles(files = files)
Copy link
Contributor

Choose a reason for hiding this comment

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

ah, that's what I missed.
wouldn't it be simpler to add it to the //:stdlib rule ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'd rather keep this in the GoStdLib provider for now, but I don't have a strong opinion about it, since this isn't a public interface. Fewer things to keep in sync though.

}
return filepath.Walk(path, visit)
}
if filepath.Base(path) == "fmt.a" {
Copy link
Contributor

@steeve steeve Apr 18, 2018

Choose a reason for hiding this comment

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

unfortunately fmt is not a good candidate because pure go packages where producing the same build ids. (even though we're checking that they are absent I know)

that said, we should check 3 types of packages:

  • the ones pure go (fmt looks like one)
  • the ones with asm (crypto/* are in that case I think)
  • the ones with cgo (os/user comes to mind)

You can find the list at #1391 (comment), perhaps check fmt and the ones from the list ?

Copy link
Contributor

Choose a reason for hiding this comment

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

it's likely it'll be the same but for the sake of correctness and future proofing...

Copy link
Contributor

Choose a reason for hiding this comment

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

also, we should probably check for the sandbox path by binary search for bazel-sandbox for cgo packages because of f4201a5

but that may out of the scope of this PR though

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Very good advice. I've expanded the test to check fmt.a, crypto/aes.a, and runtime/cgo.a. That should cover those cases.

About searching for bazel-sandbox, tests/legacy/reproducible_binary checks for common reproducibility problems in compiled binaries, but I wrote it before bazel-sandbox appeared it paths, so it should be updated (in another PR).

}
return filepath.Walk(path, visit)
}
if filepath.Base(path) == "fmt.a" {
Copy link
Contributor

Choose a reason for hiding this comment

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

also, we should probably check for the sandbox path by binary search for bazel-sandbox for cgo packages because of f4201a5

but that may out of the scope of this PR though

@jayconrod jayconrod merged commit fbadad3 into bazelbuild:master Apr 19, 2018
@jayconrod jayconrod deleted the check-stdlib-buildid branch April 19, 2018 18:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants