25 Feb, 2020

2 commits


13 Feb, 2020

1 commit

  • When running our tests there are some cases where as part of the Python
    2.7 to Python 3.6 migration we didn't force Python 3.6 to be used as
    everything wasn't yet migrated. Now that everything is, make sure to
    tell virtualenv to use python3. In the case of Travis this is best done
    by making the tools test happen after the main tests so that it will
    already have been run in all cases, TEST_PY_TOOLS is a subset of
    TEST_PY_BD.

    Signed-off-by: Tom Rini

    Tom Rini
     

12 Feb, 2020

1 commit


11 Feb, 2020

1 commit


08 Feb, 2020

2 commits


06 Feb, 2020

1 commit


21 Jan, 2020

1 commit


11 Jan, 2020

1 commit


07 Nov, 2019

1 commit


31 Oct, 2019

4 commits

  • As things stand today, we have tools that CI requires where "python"
    must be "python2". We need to use a virtualenv and pip in order to
    ensure that our pytest tests can be run. Rework things slightly so
    that:
    - On Travis-CI, we install python-pyelftools for the platforms that
    require pyelftools to be installed.
    - On GitLab-CI, we move to a newer base image that includes python3-pip
    and continue to use a virtualenv per job that needs it, for the
    correct set of packages.

    Reviewed-by: Simon Glass
    Tested-by: Stephen Warren
    Tested-by: Simon Glass [on sandbox]
    Signed-off-by: Tom Rini

    Tom Rini
     
  • Fix the following spit from pytest:

    u-boot/test/py/conftest.py:438: RemovedInPytest4Warning: MarkInfo objects are deprecated as they contain merged marks which are hard to deal with correctly.
    Please use node.get_closest_marker(name) or node.iter_markers(name).
    Docs: https://docs.pytest.org/en/latest/mark.html#updating-code
    for board in mark.args:

    In both cases, the later suggestion is applicable.

    Reviewed-by: Stephen Warren
    Reviewed-by: Simon Glass
    Signed-off-by: Marek Vasut
    Cc: Igor Opaniuk
    [trini: Update for current file with a few more cases, un-pin pytest in CI]
    Tested-by: Simon Glass [on sandbox]
    Tested-by: Stephen Warren
    Signed-off-by: Tom Rini

    Marek Vasut
     
  • Currently we set the entire PATH rather than prepend the new paths that
    we need to have searched. This however breaks parts of the "virtualenv"
    that was have set up and need to use as that also will be modifying
    PATH. To fix this, prepend our new locations instead.

    Reviewed-by: Stephen Warren
    Reviewed-by: Simon Glass
    Tested-by: Stephen Warren
    Signed-off-by: Tom Rini

    Tom Rini
     
  • In a number of our stanzas we had multi-line commands that were one
    space short of alignment, correct this.

    Reviewed-by: Stephen Warren
    Reviewed-by: Simon Glass
    Tested-by: Stephen Warren
    Signed-off-by: Tom Rini

    Tom Rini
     

09 Oct, 2019

2 commits


07 Oct, 2019

1 commit


25 Sep, 2019

1 commit


13 Aug, 2019

2 commits


02 Aug, 2019

2 commits


29 Jul, 2019

1 commit


25 Jul, 2019

4 commits


18 Jul, 2019

5 commits

  • We need this for building some 64bit ARM platforms, not for test.py
    runs.

    Signed-off-by: Tom Rini

    Tom Rini
     
  • To better allow for parallelization of the world build job split things
    into 32bit ARM (687 boards), 64bit ARM (215), PowerPC (311 boards) and
    everything else (167 boards).

    While the 32bit ARM job is heavier than I would like, there is not a
    natural split that would reduce it in half or so without requiring the
    sort of hard to maintain splits we have to do in Travis CI.

    Signed-off-by: Tom Rini

    Tom Rini
     
  • In order to mirror current Travis CI support we need to install this
    package via pip.

    Signed-off-by: Tom Rini

    Tom Rini
     
  • Bring us back into line with current Travis tests.

    Signed-off-by: Tom Rini

    Tom Rini
     
  • Migrate all of the logic in our current .travis.yml file to a GitLab CI
    config file. Notable changes are that this will run the jobs on runners
    with the "all" tag. The timeout for a job needs to be configured higher
    than normal as we no longer split building the world up into a large
    number of small jobs but instead perform one big build job. We make use
    of stages so that we build and run all of the QEMU + test.py tests first
    in order to increase the chance that any problems will be found before
    starting the final big build.

    Signed-off-by: Tom Rini

    Tom Rini