Open mkpankov opened 5 years ago
Your config is not complete:
Container "ciri-redist" referenced from "pavetta-sdk-common" is not found
Also there is no ciri-lua
and sdk-custom
containers in the config.
@anti-social will post more complete config on work week, though it still references proprietary code...
I've updated the first comment and added those you mentioned, and two files used to generate a sub-config.
As for ciri, pavetta and SDK deb packages, I currently can't share them. In case it reproduces with dummy rust projects / dummy deb, it's gonna be great. Meanwhile I'll try to minimize the example.
This error means that container version changes during the build of that container. At a glance, I don't see any obvious conflicts here. But maybe it's because of things you've stripped. The most common case is when you !Depend
on some files in /work
but modify them during the build.
In that case, you should put the result of the build into the container itself (i.e. in /usr/share
of say container A), and container (B) that depends on it should depend on A rather than on the file in /work
. (At a glance, it seems you do that right in most cases, but probably there is tiny one place that fails at it)
The !Depend
command is either for things that are checked out from VCS, or for things that other external commands do, not as a part of build process of any container.
First two paragraphs make sense.
The last one perplexes me however. Is that correct that I !Depend
on Cargo.toml
and src
in container, that builds a Rust project and puts the binary to /usr/local/bin
in the container?..
There Rust sources are in the VCS, via a submodule repo.
Is that correct that I !Depend on Cargo.toml and src in container, that builds a Rust project and puts the binary to /usr/local/bin in the container?..
Yes, it looks like perfectly correct.
By the way, there is a way to debug dependencies:
vagga _version_hash --debug-versioning pavetta-redist
Try it before and after bulding pavetta-redist
container and it should show you differences. If output is the same, then referred files differ (you can use --dump-version-date
to compare data itself, but most of the time, looking at file
entries in --debug-versioning
should be enough to find out which unexpected files are referred).
Okay so I tried that.
I've built pavetta-sdk-custom
, which builds pavetta-sdk-common
, which builds pavetta-redist
. Dumped the version data (both --debug-versioning
and --dump-version-data
).
Then I've added a println!("");
to one function in src/main.rs
in pavetta
.
Dumped the version data - as expected, it's the same, except for that line and final hash.
Then I've build pavetta-redist
and pavetta-sdk-custom
.
Dumped the version data - and again, as expected, it's the same, except for that line and final hash.
Any more pointers on where to look?
Does vagga interact with git or submodules in particular?
Can you clarify the following from !Build
docs?
Despite the name Build dependencies are not rebuilt. The Build command itself depends only on the container but on on the individual files. You need to ensure that the source container is versioned well (sometimes you need Copy or Depends for the task)
Also, in docs for content-hash
option:
The container in (1) is not binary reproducible (i.e. every build could possibly produce different checksums)
Might that be the case? Like, maybe cargo puts compilation date into binary or something?..
Tried building and then rebuilding the pavetta-redist
with --force
- hash of rust binary is the same.
I've been able to produce a minimal example using a simple "Hello, world" rust program.
https://github.com/mkpankov/vr
To reproduce the problem, you have to build once with vagga pavetta
, then edit pavetta/src/main.rs
- change one println
to the other, then run vagga pavetta
again.
Even though the pavetta-redist
is properly rebuilt in the beginning, in the end there's
WARN 2019-09-10T15:09:20Z: vagga::builder::commands::subcontainer: Can't write image usage info: No such file or directory (os error 2)
ERROR 2019-09-10T15:09:20Z: vagga::builder: Error building container "pavetta-sdk-common": step Build { container: "pavetta-redist", source: "/usr/local/bin", path: Some("/usr/local/bin"), temporary_mount: None, content_hash: false, rules: ["/pavetta"] } failed: can't read "/vagga/base/.roots/pavetta-redist.1c729ece/root/usr/local/bin": No such file or directory (os error 2)
ERROR 2019-09-10T15:09:20Z: vagga::wrapper: Error executing _build: Builder exited with code 1
Command <Command "/proc/self/exe" "__wrapper__" "_build" "pavetta-sdk-custom"; environ[7]; uid_map=[UidMap { inside_uid: 0, outside_uid: 1000, count: 1 }, UidMap { inside_uid: 1, outside_uid: 100000, count: 65535 }]; gid_map=[GidMap { inside_gid: 0, outside_gid: 1000, count: 1 }, GidMap { inside_gid: 1, outside_gid: 100000, count: 65535 }]> exited with code 124
I suspect the issue is that there's untracked state in /work/.vagga-ws/pavetta/target
- it's cargo output directory, and I think it can touch it intermittently (didn't check that yet).
Well, these are offending lines:
- !Sh |
cd pavetta
cargo build --target-dir /work/.vagga-ws/target/pavetta
- !Copy
source: /work/.vagga-ws/target/pavetta/debug/pavetta
path: /usr/local/bin/pavetta
Because source
in !Copy
are in /work
, they are hashed before building container to make a container hash. Then after container is built the contents of the file change and new container hash is different.
The fix is easy: put --target-dir
into a container itself (e.g. /tmp
) or into a cache dir. Another hack would be to just cp [..snip..]/pavetta /usr/local/bin
instead of using !Copy
because you don't need to hash a binary if you already hashed sources (this happens when you !Copy
not from a /work
anyway).
I started with simple cp
, but it didn't work (the same way as now). I'll try rolling it back in the minimal example.
So yeah, it did help in the minimal example... problem is, simple cp ...
is what I started with in my actual project, and it didn't work... Will dig further.
Found the actual issue. This commit makes it fail in all cases (even initial build is not successful).
https://github.com/mkpankov/vr/commit/2f17b70c0d54d0e85b7f85f6d3dce2e499c70d5d
I've also reduced the reproduction repository to not include any compilation. Problem is present when simply depending on files, copying them into container, using this container in !SubConfig
via !Build
. Changing !SubConfig
to !Container
fixes the issue but is not applicable in all cases.
If I were to try and fix this, where in the sources should I be looking?
Well, thank you for finding this out! It's really a bug, but not trivial to fix:
!Container
vagga.yaml
for !SubConfig
might not be existent at the moment of initial versioning (this was the original intention of !SubConfig
).Now (1) requires changing internal API, which isn't very hard. But it might be non-trivial to keep use-case (2) functioning in all cases.
On the other hand, in trivial cases of subconfig where yaml isn't generated you can use sequence unpacking:
pavetta-sdk-common:
setup: &pavetta-sdk-common
- !Ubuntu bionic
- !UbuntuUniverse
- !Install [build-essential]
- !Build
container: pavetta-redist
source: /usr/local/bin
path: /usr/local/bin
rules:
- /pavetta
pavetta-sdk-custom:
environ:
HOME: /work/.vagga-ws
setup:
- !Unpack [*pavetta-sdk-common]
- !Install [whatever, else, you, need]
Extra thoughts:
It became easier to spot when I enabled debug log (RUST_LOG=info vagga pavette
), there was no container pavetta-redist
built before the pavetta-sdk-custom
If we are to fix the bug, the stumble block isn't non-existent vagga.yaml
where !SubConfig
sources data from (it can be achieved by returning Version::New
when no config preset), but the fact that generated vagga.yaml
may contain new dependencies. I'm not sure the latter is easy to make working.
Hi, I need help with an issue I'm encountering consistently on my project. I couldn't minimize it yet - maybe you can tell what's wrong already. This issue occurs when directly building final container
pavetta-sdk-custom
, but if we first buildpavetta-redist
, it goes away. There's also a warning I don't know how to handle:Relevant configs are:
prepare-sdk-yaml.py:
sdk-spec.template.yaml: