project-oak / oak

Meaningful control of data in distributed systems.
Apache License 2.0
991 stars 107 forks source link

Pass package name from buildconfig to Ent upload #5001

Closed thmsbinder closed 3 months ago

thmsbinder commented 3 months ago

Changes required for importing a provenance for e.g. oak_containers_kernel or oak_containers_stage1 using the TR import tool:

b/332534337

Fixes (hopefully) b/333327209

tiziano88 commented 3 months ago

I must be missing some context -- why do we need to specify both artifact_path and binary_name in most (but not all) the build config files, and why are they always / usually identical? How would people decide how to populate those going forward?

thmsbinder commented 3 months ago

This is to address the wildcard issue: artifacts_path may contain wildcards, binary_file must not contain wildcards. For TR import, we only ever need bzImage, but via artifacts_path we also see image and setup data files. For TB we need to index all three files.

That said, the tag name for TB use is ambiguous. We should use

artifact_${GITHUB_SHA}_${package_name}_${binary_name}

For example:

artifact_123_oak_containers_kernel_bzImage

WDYT?

jul-sh commented 3 months ago

I think we can solve this a little more elegantly, will show an example in a moment.

jul-sh commented 3 months ago

I must be missing some context -- why do we need to specify both artifact_path and binary_name in most (but not all) the build config files, and why are they always / usually identical? How would people decide how to populate those going forward?

basically the issue @thmsbinder identified is that we want the filename of the binary in the provenance, as well as its tag on ent, to match the binary we build in kokoro and import into google3. The kokoro filename is defined here: https://github.com/project-oak/oak/blob/023495837b2f96308ac3048f7b32968e5d3a3138/kokoro/build_binaries_rust.sh#L46