This patch adds the top-level `overrides` entry, which is used to
override (or pin) the refspec of repositories. The main difference to a
direct override is that this logic only applies to repos that are
already defined. By that, a superset of all repos can be added to this
entry (similar to a global lockfile), but only the currently active ones
are affected. A new top-level keyword is required because everything
below the "repos" keyword is potentially defined by "default" values.
For the locking mechanism, a clear separation between overrides (only
override if existing) and definitions is required to be able to define a
global lockfile with all possible repos, while just defining some repos.
Proposed-by: Ross Burton <ross@burtonini.com>
Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
[Jan: also bump __file_version__]
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Until now all environment variables in the kas config's
env section require a default value.
In some cases we want to rely on the weak assignment
of bitbake instead of relying on the default value of the
variable in the kas config.
This means if we assign the 'None' value or nothing to the variable
in the kas config then it is only added to BB_ENV_EXTRAWHITE or
BB_ENV_PASSTHROUGH_ADDITIONS without setting it as environment
variable.
Signed-off-by: Benedikt Niedermayr <benedikt.niedermayr@siemens.com>
[Jan: fixed overlong line]
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Make "null" an allowed type for the `url` and `path` properties of a
repository. This allows "deleting" them in an override kas-file to e.g.
point a repository at a local directory instead of a git remote:
"Original" file:
repos:
meta-foo:
url: https://example.org/foo.git
refspec: badc0ffee
Override:
repos:
meta-foo:
url:
path: /path/to/local/foo
Without the explicit "nulling" of the URL, kas would start messing with
the repo in /path/to/local/foo (changing remote URL, switching to a
different rev, etc.). With this change, we can instead force kas to use
the recipes in that directory untouched.
Signed-off-by: Harald Seiler <hws@denx.de>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
This allows to pre-select the build system, specifically avoiding
confusion when kas-container is accidentally not called with --isar for
an isar config. For that, build_system needs to be defined in the
lop-level config file passed to kas-container.
Theoretically, this also allows to combine layers which have both
oe-init-build-env and isar-init-build-env scripts.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Also update config file version to 9 due to this format change.
Signed-off-by: Paul Barker <pbarker@konsulko.com>
[Jan: style fix]
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
With this commit its now possible to patch 3rd party repos before bitbake is started.
Example:
This is our repo:
.
├── kas.yml
├── first-patch.patch
└── quilt-patches
├── second-patch.patch
├── third-patch.patch
└── series
Content of kas.yml:
header:
version: 8
repos:
my:
third-party:
url: "git://example.com/third-party.git"
refspec: "35adf4...34"
patches:
01-first:
repo: my
path: "first-patch.patch"
02-second:
repo: my
path: "quilt-patches"
Currently only 'git' repositories can be patched.
Signed-off-by: Claudius Heine <ch@denx.de>
This will be used to carry the type of repo we are talking about. At the
moment it defaults to "git".
Signed-off-by: Henning Schild <henning.schild@siemens.com>
With this its possible to create custom environment variables within the kas
configuration file, that are passed through to the build environment:
env:
VARIABLE_NAME: "default variable value"
Those variables can be overwritten by variables of the environment kas is
started in:
$ VARIABLE_NAME="overwritten variable value" kas shell ...
Those variables are also added to the 'BB_ENV_EXTRAWHITE' variable list to make
them available to bitbake.
This is useful for instance storing sensitive information, that should not be
part of the configuration files or bitbake recipes.
Signed-off-by: Claudius Heine <ch@denx.de>
This patch adds multiconfig support to kas by defining the
"BBMULTICONFIG" variable in the "local.conf" file.
Signed-off-by: Claudius Heine <ch@denx.de>
Since its easy to forget to update the documentation when changing the
configuration file format version, this patch adds a small note to
remind the developer about it.
Signed-off-by: Claudius Heine <ch@denx.de>
With this patch support for building multiple targets in parallel with
bitbake is now supported.
Changes:
- Its now possible to state a list of targets under the target key in
the configuration file.
Example:
target:
- product-image
- product-update-image
- Its now possible to define multiple targets in the kas command line.
Example:
$ kas build --target product-image --target product-update-image \
kas.yml
- Its now possible to define multiple targets via the environment:
Example:
$ export KAS_TARGET="product-image product-update-image"
$ kas build kas.yml
Signed-off-by: Claudius Heine <ch@denx.de>
Captain Hindsight: We should have never committed 13a87cb8c7 ("Allow
to define task in config and environment") without forwarding the file
version. Without this, no config file writer can tell kas versions
apart that support task control from those that don't.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
