f2560588bc
This patch reworks the logic when setting KAS_REPO_REF_DIR. When this variable is set, a two-staged clone is used: First, a bare-clone (or similar) is created in the ref-dir, according to the naming scheme. This clone is executed in a way that is both reentrant as well as race-free across multiple instances of KAS working on the same dir. Internally we clone into a tmpdir below the refdir and rename on success to guarantee the atomicity of the operation on POSIX compliant filesystems. Second, the clone in the KAS_WORK_DIR is executed against the local copy. After that, the origin url is redirected to the upstream url. By that, the KAS_REPO_REF_DIR directory can be cached across builds which significantly speedsup clone times against large repos. In case the requested refspec is already in the cache (very likely in CI builds), no direct access to the upstream repo is required. This logic is crucial for CI systems in China, where e.g. access to github is blocked from time to time. The clone-from-local logic is currently only implemented for the git plugin as HG misses the caching logic. Repo implementations that do not support this logic can simply opt-out for the first stage by returning 'true'. The existing user-facing logic of KAS_REPO_REF_DIR is not affected. However, internally we no longer clone via --reference as this still requires access to the remote repo, even if the requested commit is already in the local copy. Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> |
||
|---|---|---|
| .github | ||
| contrib | ||
| docs | ||
| image-tests | ||
| kas | ||
| scripts | ||
| tests | ||
| .dockerignore | ||
| .flake8 | ||
| .gitignore | ||
| .readthedocs.yaml | ||
| CHANGELOG.md | ||
| container-entrypoint | ||
| CONTRIBUTING.md | ||
| Dockerfile | ||
| kas-container | ||
| kas-docker | ||
| LICENSE | ||
| pyproject.toml | ||
| README.rst | ||
| run-kas | ||
| setup.py | ||
Setup tool for bitbake based projects ===================================== +--------------------+ | Build Status | +====================+ | |workflow-master|_ | +--------------------+ | |workflow-next|_ | +--------------------+ .. |workflow-master| image:: https://github.com/siemens/kas/workflows/master/badge.svg .. _workflow-master: https://github.com/siemens/kas/actions?query=workflow%3Amaster .. |workflow-next| image:: https://github.com/siemens/kas/workflows/next/badge.svg .. _workflow-next: https://github.com/siemens/kas/actions?query=workflow%3Anext This tool provides an easy mechanism to setup bitbake based projects. The OpenEmbedded tooling support starts at step 2 with bitbake. The downloading of sources and then configuration has to be done by hand. Usually, this is explained in a README. Instead kas is using a project configuration file and does the download and configuration phase. Key features provided by the build tool: - clone and checkout bitbake layers - create default bitbake settings (machine, arch, ...) - launch minimal build environment, reducing risk of host contamination - initiate bitbake build process See the `kas documentation <https://kas.readthedocs.io>`_ for further details.