tests/mcuboot: handle building in docker #11083
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
cladmi
added
Type: enhancement
cladmi
added
the
CI: ready for build
cladmi
added
Type: bug
6 tasks
|
I was just thinking, and I think that the same solution could be solved by only setting |
|
The handling with |
cladmi
added
the
State: waiting for other PR
|
Let's wait for the other pull requests, I may get it through. |
|
PR merged, please rebase. |
cladmi
force-pushed
the
pr/docker/hack/bootloader
branch
from
d22a22a
to
ca0daee
Compare
cladmi
changed the title
|
I remove the However, I noticed in the same time, that for It would just fix doing So not sure this is really helping, except the compilation… |
|
@cladmi, is this PR still waiting for another PR ? It doesn't seem to. |
cladmi
force-pushed
the
pr/docker/hack/bootloader
branch
from
ca0daee
to
4465fc2
Compare
cladmi
removed
the
State: waiting for other PR
|
@aabadie no it does not depend anymore. It would however only fix building in docker as said in my previous comment. But at least the compilation does not fail when you do I rebased and updated the commit message to explain this. |
cladmi
added
CI: ready for build
When using BUILD_IN_DOCKER only make 'all' execute 'mcuboot' target when inside the container. Otherwise it will execute it using your host toolchain. This is a hack and could be prevented by having a file target put in FLASHFILE. This does currently not allow flashing after building in docker as flashing should be done with `mcuboot-flash` which will not be done in docker. It would require the `FLASHFILE` fix to be done properly.
cladmi
force-pushed
the
pr/docker/hack/bootloader
branch
from
4465fc2
to
24a54fe
Compare
|
Rebased in case something broke in between. |
This was referenced Jul 10, 2019
MrKevinWeiss
added
CI: run tests
|
Tested this fixes the building Issue: PR:BOARD=nrf52dk BOARDS=nrf52dk PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin BUILD_IN_DOCKER=1 make -C tests/mcuboot/ allmaster:BOARD=nrf52dk BOARDS=nrf52dk PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin BUILD_IN_DOCKER=1 make -C tests/mcuboot/ all |
fjmolinas
added
Reviewed: 1-fundamentals
|
@cladmi does this still need to wait for something? |
|
No it is not waiting for anything. |
|
Thank you for the review. I will rebase and update the testing procedure. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Contribution description
When using BUILD_IN_DOCKER only make 'all' execute
mcuboot/riotboottarget wheninside the container. Otherwise it will execute it using your hosttoolchain.
This is a hack as it cannot currently be handled at the
mcuboot/riotboottarget level.Hack and not a fix
I know it is a hack and not a library level fix.
Fixing it at
dockerlevel is currently harder with the way the integration is done, I tried but requires more changes that I hoped. I prefer put this HACK to make it usable until a proper fix can go in.Testing procedure
If your
arm-none-eabi-gcccompiler is outside of/usr/binand you can define a working PATH not includingarm-none-eabi-gccyou can try the following. (or have a machine withoutarm-gcc):Compiling either
tests/mcubootortests/riotbootwith docker would fail as it would be trying to use your local toolchain.Fixed now
Even flashing is now handled with this pull request:
Flashing and test works with
samr-21forriotbootand I can flash fortests/mcubootwith thenrf52dk. Note themcubootfirmware is broken for me both on master and with this PR.`DOCKER="sudo docker" BUILD_IN_DOCKER=1 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin make -C tests/riotboot flash test`
`DOCKER="sudo docker" BUILD_IN_DOCKER=1 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin make -C tests/mcuboot/ flash`
Verify it is failing in master
`DOCKER="sudo docker" BUILD_IN_DOCKER=1 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin make -C tests/mcuboot/`
`DOCKER="sudo docker" BUILD_IN_DOCKER=1 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin make -C tests/riotboot/`
Issues/PRs references
Running compilation on a machine without toolchain installed.
Tracking issue #9645