Hi Tom,
On Wed, 26 Jul 2023 at 07:23, Tom Rini trini@konsulko.com wrote:
On Wed, Jul 26, 2023 at 03:16:38PM +0530, Sughosh Ganu wrote:
On Wed, 26 Jul 2023 at 04:26, Tom Rini trini@konsulko.com wrote:
On Tue, Jul 25, 2023 at 04:52:38PM -0600, Simon Glass wrote:
On Tue, 25 Jul 2023 at 02:58, Sughosh Ganu sughosh.ganu@linaro.org wrote:
Support has being added through earlier commits to build capsules and embed the public key needed for capsule authentication as part of u-boot build.
From the testing point-of-view, this means the input files needed for generating the above have to be setup before invoking the build. Set this up in the CI configuration docker file for testing the capsule update feature.
Signed-off-by: Sughosh Ganu sughosh.ganu@linaro.org
Changes since V4:
- New patch which moves the setting up of the files needed for testing the EFI capsule update feature to the Dockerfile.
Note: Earlier, this setup was being done in the azure and gitlab yaml files. Now that this has been moved to the Dockerfile, this will require generating a new container image and referencing that image in the yaml files for the CI to work when these patches get applied.
tools/docker/Dockerfile | 12 ++++++++++++ 1 file changed, 12 insertions(+)
diff --git a/tools/docker/Dockerfile b/tools/docker/Dockerfile index 3d2b64a355..294a0b0a53 100644 --- a/tools/docker/Dockerfile +++ b/tools/docker/Dockerfile @@ -206,6 +206,18 @@ RUN mkdir -p /opt/nokia && \ cp /tmp/qemu-linaro/arm-softmmu/qemu-system-arm /opt/nokia && \ rm -rf /tmp/qemu-linaro
+# Set up capsule files for UEFI capsule update testing +RUN mkdir -p /tmp/capsules && \
- cd /tmp/capsules/ && \
You can just use ${UBOOT_TRAVIS_BUILD_DIR} here
That's not present in Dockerfiles, only at runtime within jobs (because we set it).
I can copy the files into UBOOT_TRAVIS_BUILD_DIR as part of the job, similar to what is being done for the grub*.efi files.
Yes, copying the files rather than relying on them being in /tmp is better, but..
- echo -n "u-boot:Old" > u-boot.bin.old && \
- echo -n "u-boot:New" > u-boot.bin.new && \
- echo -n "u-boot-env:Old" > u-boot.env.old && \
- echo -n "u-boot-env:New" > u-boot.env.new && \
We don't want these files, just the certs, since they are the things that take a long time:
- openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_SIGNER/ -keyout SIGNER.key -out SIGNER.crt -nodes -days 365 && \
- openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_SIGNER/ -keyout SIGNER2.key -out SIGNER2.crt -nodes -days 365 && \
- cert-to-efi-sig-list SIGNER.crt SIGNER.esl && \
- chmod -R uog+rw /tmp/capsules/
How long does it even take to make these certs? I'm not sure it's great to make these and stage them in /tmp and expect them to be around at test time.
Should I mimic what is being done for the various grub.efi files? I believe that these are in the /opt/grub/ directory of the docker image, and get copied to the build dir at runtime.
It takes 10 minutes or so to build grub, and we use it in multiple tests. Running openssl takes not even a second. Why are we doing this in the Dockerfile? Is this needed in more than one test? If so, does it matter if we have the same certs in each test?
Yes it is actually much faster that I expected, so I suppose we can go back to having it in the test itself, e.g. in a pytest fixture.
Regards, Simon