1. 29 Apr, 2021 1 commit
  2. 28 Apr, 2021 4 commits
    • Zygmunt Krynicki's avatar
      .ostc-ci: sprinkle ample quantity of "set -ex" · 17d013e6
      Zygmunt Krynicki authored
      It seems that GitLab CI is not running with `set -e` but a weaker
      equivalent, as evidently proven by the recent discovery of incorrect
      shell syntax going unnoticed.
      While unconfirmed it seems that what is going on is that each of the
      `before_script`, `script` and `after_script` sections being combined
      into *lists* and executed in distinct processes, one by one. A simple
      command, such as `false`, reports its status through the exit code of
      bash. Compound commands that run multiple processes as a single element
      of the various script sections, can have internal failures without
      immediately stopping execution.
      To shed some light, add `set -ex` in all the jobs that don't already
      inherit it with the job extension mechanism.
      Signed-off-by: Zygmunt Krynicki's avatarZygmunt Krynicki <zygmunt.krynicki@huawei.com>
      Change-Id: If41b71e5cca3c58d1c6ed163fb9bd147c2d14481
    • Andrei Gherzan's avatar
    • Andrei Gherzan's avatar
      build-generic.yaml: Fix workspace setup on fork pushes · 3857269e
      Andrei Gherzan authored
      When an MR is raised from a fork, GitLab does a merge operation from
      source to target. The resulting SHA is used as CI_COMMIT_SHA, which
      reside neither in source nor in target - it's a temporary merge in the
      scope of the CI validation.
      This change fixes the assumption that CI_COMMIT_SHA is in source by
      reusing the setup GitLab done in CI_PROJECT_DIR.
      Signed-off-by: default avatarAndrei Gherzan <andrei@gherzan.com>
    • Zygmunt Krynicki's avatar
      .ostc-ci: fix typo preventing usage of git-repo cache · d4adb31f
      Zygmunt Krynicki authored
      During one of the OSTC/OHOS rename sprees I must have made the mistake
      of renaming {OSTC,OHOS}_MANIFEST_MIRROR variable partially, having the
      definition right but the usage wrong. This resulted in CI not really
      using the git cache at all, making everything extremely slow if the
      remote git repositories were under load.
      There's a separate mystery as to why this was not breaking the script on
      undefined variable, but I will address that separately.
      Signed-off-by: Zygmunt Krynicki's avatarZygmunt Krynicki <zygmunt.krynicki@huawei.com>
      Change-Id: Ie81dd232a782f78cc646fdcee1ca1f31cec5ce11
  3. 23 Apr, 2021 2 commits
  4. 21 Apr, 2021 4 commits
  5. 20 Apr, 2021 4 commits
  6. 08 Apr, 2021 2 commits
    • Zygmunt Krynicki's avatar
      build-generic: refactor and document job templates · 590b10c4
      Zygmunt Krynicki authored
      Split the existing .workspace and .build jobs into the following:
      - .workspace - handling git-repo and single-repository CI override
      - .bitbake-workspace - handling bitbake customizations, including recipe CI
      - .build-{linux,zephyr,freertos} - build a tailored set of recipes
      - .build-recipe - build a single recipe
      - .build-image - build a single recipe and collect the resulting image
      - .build - (deprecated) - alias for .build-recipe
      This should keep compatibility with downstream CI (meta-ohos and others)
      but allow the docs repository to reuse the .workspace job entirely.
      In addition, document all the jobs with reStructured Text, moving some
      of the text from the implementation (yaml) files, into new documentation
      chapters. Existing documentation is slightly re-structured to take the
      new implementation details into account.
      In last addition, the .workspace job is no longer strict about presence
      of a directory called "sources/". This prevented re-using the job for
      gitee builds.
      Signed-off-by: Zygmunt Krynicki's avatarZygmunt Krynicki <zygmunt.krynicki@huawei.com>
    • Zygmunt Krynicki's avatar
      .gitignore: Rewrite ignore rules · adee6b8b
      Zygmunt Krynicki authored
      The ignore rules made little sense, since building, with bitbake, in the
      manifest repository, directly, is not standard practice. Replace
      existing rules with something that makes sense for general editing and
      documentation work.
      Signed-off-by: Zygmunt Krynicki's avatarZygmunt Krynicki <zygmunt.krynicki@huawei.com>
  7. 07 Apr, 2021 4 commits
  8. 01 Apr, 2021 2 commits
  9. 31 Mar, 2021 2 commits
  10. 30 Mar, 2021 2 commits
    • Zygmunt Krynicki's avatar
      build-generic.yaml: merge all pipelines into one file · b3b55708
      Zygmunt Krynicki authored
      This step simplifies process of including and correctly configuring the
      pipeline in other repositories. It will also unlock refactoring, mainly
      aimed at removing the .build job entirely, and moving the precise
      functionality to one of the flavour-specific jobs,
      .build-{linux,zephyr,freertos} instead.
      For backwards compatibility, the two empty files are retained
      to allow older pipelines not to fail on missing import file.
      Signed-off-by: Zygmunt Krynicki's avatarZygmunt Krynicki <zygmunt.krynicki@huawei.com>
    • Andrei Gherzan's avatar
      default.xml: Unpin ip-policy project · 3e698788
      Andrei Gherzan authored
      We initially pinned it because we thought that explicit bumps would not
      be needed often. The issue though comes when updating the docs through
      the CI when changes are done in the ip-policy repository. If the project
      is pinned, docs aggregation will not pick anything new because the
      manifest, which is used when creating the docs workspace, will not
      change for ip-policy.
      Signed-off-by: Andrei Gherzan's avatarAndrei Gherzan <andrei.gherzan@huawei.com>
      Change-Id: Ic527548bf172fafeef5cbe486dc6581050e93580
  11. 29 Mar, 2021 3 commits
  12. 26 Mar, 2021 6 commits
  13. 25 Mar, 2021 4 commits