On 7/12/20 12:05 AM, Heinrich Schuchardt wrote: > On 7/11/20 2:16 PM, Tom Rini wrote: >> On Sat, Jul 11, 2020 at 09:00:16AM +0200, Heinrich Schuchardt wrote: >>> On 7/10/20 8:09 PM, Tom Rini wrote: >>>> On Thu, Jul 09, 2020 at 06:12:02PM +0200, Heinrich Schuchardt wrote: >>>> >>>>> The following changes since commit >>>>> 61608f395e7dcb2be6060407a72a1149b046430a: >>>>> >>>>> Merge branch '2020-07-08-misc-features-and-fixes' (2020-07-08 20:20:24 >>>>> -0400) >>>>> >>>>> are available in the Git repository at: >>>>> >>>>> https://gitlab.denx.de/u-boot/custodians/u-boot-efi.git >>>>> efi-2020-10-rc1-2 >>>>> >>>>> for you to fetch changes up to f4cef8e7585c268f05a8c39e368ca115c25e40d5: >>>>> >>>>> efi_selftest: adjust runtime test for variables (2020-07-09 12:08:41 >>>>> +0200) >>>>> >>>> >>>> NAK. This is reliably failing here: >>>> https://gitlab.denx.de/u-boot/u-boot/-/jobs/122018 >>>> >>>> I see it passed Azure, and hasn't run through Travis yet. Maybe it >>>> needs to be run repeatedly to fail and we just got "lucky" ? >>>> >>> >>> Hello Tom, >>> >>> you saw unreproducible results with multiple runs failing and one run >>> succeeding. The reason is that when signing with sign-efi-sig-list in >>> out Python tests without passing a timestamp two signatures may be in >>> the same second or not. >>> >>> When using the signed files to set UEFI variables a variable can only be >>> overwritten by a file with a newer timestamp. But without setting >>> timestamps explicitly using parameter -t passed to sign-efi-sig-list we >>> have no control. >>> >>> I already fixed this for some elder tests but missed to fix this for the >>> merged patches from Takahiro. >> >> Ah, thanks for the explanation. >> > > Hello Tom, > > what I still do not understand why tests are sometimes skipped and > sometimes not for the same source code: > > https://gitlab.denx.de/u-boot/u-boot/-/jobs/122018 > Commit 7068e523 > > 140 test/py/tests/test_efi_secboot/test_authvar.py ..... > 141 test/py/tests/test_efi_secboot/test_signed.py .....F > 142 test/py/tests/test_efi_secboot/test_unsigned.py ... > > https://gitlab.denx.de/u-boot/custodians/u-boot-efi/-/jobs/122155 > Commit 7068e523 > > 148 test/py/tests/test_efi_secboot/test_authvar.py sssss > 149 test/py/tests/test_efi_secboot/test_signed.py ssssss > 150 test/py/tests/test_efi_secboot/test_unsigned.py sss > > Both runs used the same Docker image > trini/u-boot-gitlab-ci-runner:bionic-20200526-18Jun2020 > > What influence have different versions of the Gitlab runner? > > gitlab-runner 13.1.1 > gitlab-runner 12.2.0 > > Some of our tests create and delete files in /tmp. How are parallel jobs > separated in Gitlab? > > Best regards > > Heinrich >
This information I received on the #gitlab IRC channel: Q: When using Gitlab CI for building the U-Boot project many jobs run in parallel. Some results are irreproducible. How are parallel jobs separated in Gitlab. E.g. if parallel jobs write and delete files in /tmp are these in separate Docker containers or are they in the same Docker container accessing the same directory? A: Yes, each job is a distinct docker container on a transient VM . Nothing is shared unless you use the https://docs.gitlab.com/ee/ci/yaml/#cache capability, but that wouldn't help for parallel jobs. At least: on gitlab.com, that's how it's implemented. On self-managed: depends a little on how you choose to operate your runners (e.g. shell-executor vs docker etc). Best regards Heinrich
