First pass at specifying a custom docker image #330
Conversation
|
Can I get some guidance on writing a test for this? |
Codecov Report
@@ Coverage Diff @@
## master #330 +/- ##
==========================================
- Coverage 93.23% 92.72% -0.52%
==========================================
Files 11 11
Lines 414 426 +12
==========================================
+ Hits 386 395 +9
- Misses 28 31 +3
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
|
This looks pretty good! note - we'll want an addition to the README as well once this is finalized.
Some simple unit testing around |
kjeremy
force-pushed
the
use-build-image
branch
2 times, most recently
from
1d8990e to
9875324
Compare
Signed-off-by: Jeremy Kolb <[email protected]>
|
In my testing this doesn't seem to trigger a build. Do I need to somehow copy the build_workspace.sh file into the container and execute it? |
Oh - yes, I made a mistake suggesting that image as the sysroot. Given the way the build currently works, you'll probably need to match the setup from this line on https://github.com/ros-tooling/cross_compile/blob/master/ros_cross_compile/docker/sysroot.Dockerfile#L89 Thinking about it further, this feature is probably best suited (in the first version) to just reusing an image from a prior cross-compile build. Does that sound right to you? If so, then we could somehow specify or get the name of the sysroot image from a previous test build, and run using that. |
|
That sounds reasonable. Ultimately I would like to be able to save that
earlier generated image off (push it to my gitlab registry) and refer to it
in the next invocation to actually use it.
…On Wed, Jun 30, 2021, 2:11 PM Emerson Knapp ***@***.***> wrote:
In my testing this doesn't seem to trigger a build. Do I need to somehow
copy the build_workspace.sh file into the container and execute it?
Oh - yes, I made a mistake suggesting that image as the sysroot. Given the
way the build currently works, you'll probably need to match the setup from
this line on
https://github.com/ros-tooling/cross_compile/blob/master/ros_cross_compile/docker/sysroot.Dockerfile#L89
Thinking about it further, this feature is probably best suited (in the
first version) to just reusing an image from a prior cross-compile build.
Does that sound right to you? If so, then we could somehow specify or get
the name of the sysroot image from a previous test build, and run using
that.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#330 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABBACREBSF6FYJRARHLPBF3TVNM3PANCNFSM47QMG67A>
.
|
Makes sense! That should work with this approach - the main point is we need to use a sysroot image that was generated by the tool, rather than some other bare image. |
|
It sounds like we need another argument that would override the image
generated from the previous stage.
If so could we use one of the existing customization script points to push
the image to a registry or would the program need to be modified to do that
as well?
…On Wed, Jun 30, 2021, 7:38 PM Emerson Knapp ***@***.***> wrote:
Ultimately I would like to be able to save that
earlier generated image off (push it to my gitlab registry) and refer to it
in the next invocation to actually use it.
Makes sense! That should work with this approach - the main point is we
need to use a sysroot image that was generated by the tool, rather than
some other bare image.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#330 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABBACRE7BZUUH3JFM6ISY53TVOTJFANCNFSM47QMG67A>
.
|
There's not a good way to hook this in as-is, since the customization scripts run inside a container, rather than on the host. High level, what could be done is
|
|
#285