Pull request for UEFI sub-system for efi-2020-10-rc1 (2)

[Heinrich Schuchardt]

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