Enhance _stream_subprocess to run_cmd_async, a co-routine variant of
run_cmd that the caller can use to parallelize command execution.
run_cmd becomes a simple wrapper that waits for the async variant to
complete.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Instead of writing "commit", issue a more telling log message if some
repo already contains the required hash.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
The two code paths are unfortunate. Factor out the difference and use a
single run_cmd invocation. This also adds the forgotten -q when using
a reference directory.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
The current implementation did some more hackish solution to work
around some of kas infrastructure, without changing to much.
This patch cleans this up and therefor remove the more obsure part
of the include mechansim.
Signed-off-by: Claudius Heine <ch@denx.de>
Isar allows to build Debian-based images using bitbake and the usual
layer structures. It's very similar to OE, we just need to account for
a different init script name.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
If the configuration file structure changes over time, it might
introduce incompatibilities.
This patch introduces versioning of configuration file.
Configuration files needs to add a 'version' entry into their 'header'
like this:
header:
version: '0.9'
After loading this file, the version is checked agains kas version.
Every version 'M.m.p' of kas is allowed to load configuration files with
version 'M.m' and all versions backwards up to and including
the '__compatible_version__' from kas/__version__.py
Signed-off-by: Claudius Heine <ch@denx.de>
In the current configuration file we mix between entries that are file
specific (like includes and later version) and entries that are used by
the rest of kas, that are not file specific (machine, target, repos,
etc.) It might not be obvious to differenciate between those entries.
This patch introduces a header section into the configuration file, to
contain every setting that is specific to the file and not the complete kas
configuration. The 'includes' statement is moved there, because its file
specific.
Signed-off-by: Claudius Heine <ch@denx.de>
Splitting configuration files into multiple files and implementing an
include mechanism allows to handle configurations more flexible and
allowing following scenarios:
- including kas configuration file from external meta layer into
own project
- splitting many different similar configurations into multiple files
with only a couple of common files
To include file its necessary to add a 'includes' entry into the kas
configuration. To include files from the same repo, do it like this:
-----
includes:
- ../base/base_include.yml
-----
The path is relative to the current configuration file. If they start
with a path seperator ("/") they are absolute.
To include files from a different repository, do it like this:
-----
includes:
- file: bsps/my_machine_include.yml
repo: collected_machines
repos:
collected_machines:
url: https://url.to.git.repo/
revspec: master
-----
You have to make sure that the repository definition is available
in your current file, or in any include that is available at this
point.
Yaml ("*.yml") and Json ("*.json") files are supported.
Included in this patch are also some changes to the configuration
file structure. Here is an overview:
The value of the 'repos' key is a dictionary that maps a repo identifier
to a dictionary that contains 5 entries:
- url: The url to the repository. If that is missing, no git operations
are used
- refspec: The git refspec of the repository that is used. If that is
missing the latest commit of the default branch is used.
- name: The is defines under which name the repository is stored. If
that is missing the repository identifier is used
- path: The path where the repository is stored. If no url is given and
a path is missing, the repository is referencing the repository under
which the configuration file is stored. If no url is given and a path is
specified, the repository is referencing a directory where layers might
be stored. If an url is specified, path can be used to overwrite the
default (kas_work_dir + repo.name) checkout directory.
- layers: This contains a dictionary of layers, that should be included
into the bblayers.conf. The keys are paths relative to the repository
and the values can be used to exclude layers if they are one of
"excluded", "disabled", "false", "0", "n", or "no". Also boolean values
are accepted. Any other value, including "None" means that this layer is
included into the bblayers.conf. If "layers" is missing or empty, the
repository itself is included into the bblayers. If this is specified, the
repository itself is not included into the bblayers.conf.
Signed-off-by: Claudius Heine <ch@denx.de>
It was decided that 'sublayers' is to confusing, because this term is
not used in the bitbake/openembedded context.
Signed-off-by: Claudius Heine <ch@denx.de>
Config.has_changed didn't work reliably so far, so the state cache was
only allowing to associate a work directory with configuration file.
However this was rather unintuitive, specifically when moving the work
dir to a different home - nothing told the user about the persistent
association.
We therefore agreed to remove the state cache for now. It can be
reintroduced at any time once a consistent usage model exists.
To establish a relationship to a work directory inside a shell session,
kas now evaluates the KAS_WORK_DIR environment variable.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
This shortens the include from "from .__version__ import __version__"
to "from . import __version__" within the module.
Signed-off-by: Claudius Heine <ch@denx.de>
Currently the shell provided via the 'shell' command is always '/bin/sh'
and does not have a TERM variable set. This is a rather spartan shell
experience.
With this patch we add the TERM variable to the whitelist, so that
pagers work better and made the shell binary dependent from the SHELL
environment variable. If no such variable is set, we fall back to using
'/bin/sh'.
Signed-off-by: Claudius Heine <ch@denx.de>
The ssh-agent environment variables of an ssh-agent that is running
outside the kas build system are not transfered to the bitbake
environment. This causes fetching of private git repositories to
fail.
This patch adds those variables to the environment whitelist.
Signed-off-by: Claudius Heine <ch@denx.de>
