Age | Commit message (Collapse) | Author |
|
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
|
|
|
|
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
|
|
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
This patch adds a helper trait to display maps from UUID -> Error.
It is just introduced for convenience and less code duplication, the speed of
execution is not relevant at all in this case, as if this code is executed,
we're already handling errors and aborting the execution anyways.
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
|
|
This fixes a bug: If the target file existed, but was created by another user,
the tokio::fs::copy() function was not able to overwrite it (only to empty the
file). So with this patch, we remove the file before we copy a new file to the
target location.
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
Tested-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
|
|
Because it makes logically more sense to implement Into<> here than implementing
From<> for a foreign type (Vec<>).
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
clippy complained that we cannot have a derived PartialEq and a handwritten Hash
implementation.
HashMap does not implement Hash. After some research we found that BTreeMap
implements Hash, so we can derive Hash if we use BTreeMap as a key-value type
for the `env_eq` member.
Logically they are the same and this reduces code size, so go for it.
This has the nice benefit, that we do not need to implement PartialOrd and Ord
either.
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
This patch adds the condition-filtering support in the DAG-building code for
conditional dependencies.
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
We need to refactor because we want, in the next step, add filters in the
dependency-processing mechanism, where we filter out dependencies by their
condition.
Thus, using the Package::get_self_packaged_dependences() helper fn does not work
anymore and we remove it with this patch.
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
This patch implements the matching of the condition(s) against the provided
data.
The patch includes tests for all three supported conditions.
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
This patch adds parameters for the tree-of subcommand which can be used to
change the package-DAG-building based on conditional requirements.
If a package has a dependency-condition that only includes a dependency if there
is a certain image used to build, the "image" parameter can be used to inspect
the package tree (DAG) build with that image in mind.
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
This patch extends the interface for building the package DAG with a parameter
for the data that is required to check conditions for conditional dependencies.
A "DTO" type is added for this data.
The actual condition-checking is not implemented in this patch.
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
This patch adds a conditional dependency variant to the build/runtime dependency
deserialization type(s).
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
This patch adds the first implementation for conditional dependencies in the
dependency fields (that is the "build" and "runtime" keys in the package
defintion).
This is only the deserialization-interface, not the actual condition resolving
code.
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
This patch reimplements the Dependency type as an enum.
This is required because later we want to be able to use an "if" expression in
the build dependencies, for example (not decided yet) something like
runtime = [
{
d = "libfoobar",
if = [ { has_env = [ "TARGET_RH7" ]; } ]
}
]
(no valid toml here, formatting for readability)
to make a dependency optional on a condition.
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
This patch reimplements the BuildDependency type as an enum.
This is required because later we want to be able to use an "if" expression in
the build dependencies, for example (not decided yet) something like
build = [
{
d = "libfoobar",
if = [ { has_env = [ "TARGET_RH7" ]; } ]
}
]
(no valid toml here, formatting for readability)
to make a dependency optional on a condition.
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
This is not perfect, of course, as we rather should check the load on the host
rather than some artificial number of running containers (more failed jobs
result in more running containers, which results in more scheduled to the host),
but still, this is an improvement over the previous state because utilization
did not express enough.
So the issue was that the utilization only represents the utilization of an
endpoint _from the current process_.
If butido is called three times, the same host was selected for a job because
the utilization in each butido process resulted in the same values for this
endpoint.
In practice, this resulted in a build for "gcc" to be scheduled to the same
host when butido was executed three times for "gcc" (e.g. for different
platforms).
The endresult was a load of ~70 on a host where 24 was "100% load".
This is not ideal. Checking the load of a host is not possible via the docker
API, so this is what I came up with. Now, builds are scheduled to endpoints
which have fewer running containers.
This might not result in a perfect distribution (or even a "good" one), but
still it might result in a better distribution of workload than in before this
patch.
Some completely non-artificial testing resulted in the expected behaviour.
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
Tested-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
|
|
|
|
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
Tested-by: Matthias Beyer <matthias.beyer@atos.net>
|