-
Notifications
You must be signed in to change notification settings - Fork 11
Embedding version hash and distro in string #117
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
Conversation
|
This is validated and passing on test build osrf/docker_images#809 I'm going to merge this to get the non-noetic builds working as they're the ones that aren't EOL. Noetic will likely start working again with #116 and Noetic being successfully snapshotted. @mikaelarguedas @ruffsl a post review would be appreciated. |
…e at generation time Using results of osrf/docker_templates#117
mikaelarguedas
left a comment
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.
Nice,
noticed 1 bug for EOL distros, its addressed in #116
| source_suffix = 'testing' | ||
| repo_url = f'http://packages.ros.org/ros{apt_suffix}/ubuntu' | ||
|
|
||
| # Get the latest tag |
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.
this should be in the else block as apt_suffix variable doesnt exist in the if branch
| tag_name = r.json().get('tag_name') | ||
|
|
||
| # Get the latest version and compute the checksum | ||
| fetch_url = f"https://github.com/ros-infrastructure/ros-apt-source/releases/download/{tag_name}/ros{apt_suffix}-apt-source_{tag_name}.{os_code_name}_all.deb" |
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.
Does this fundamentally solve the issue raised in docker-library/official-images#19162 (comment) (ie: should the hash not have been generated during the build of the .deb / should the hash from the build output be used)?
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 package is fetched over a TLS connection and hashed. Even if the hash was precomputed and posted somewhere, we'd still be fetching that over something like https as well, so chain of trust still inherently hinges upon the installed ca-certificates ( and integrity of the CI runtime of course).
In truth, this really only helps alleviate the library's build farm from having to interact with GitHub's public API endpoint, which is severely rate limited.
Hardcoding the public key or fingerprint would be more foolproof, but the template was being expanding that already before via "trusted" CI runtime anyhow. But I guess it would still be more apparent if the fingerprint changed in the diff review process as apposed to an ever evolving checksum of a moving target file.
This embeds everything at template generation time instead of at build time.
As per the discussion in docker-library/official-images#19162
The template genration is failing on Noetic right now due to the Noetic EOL logic. I don't think that the new index is updated on snapshots for it yet.
I'm going to look at if #116 will fix that if merged into this.