by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Karel Wintersky
    @KarelWintersky
    Solved.
    docker run --rm --user "$(id -u)":"$(id -g)" -e VAGGA_VERSION=v0.8.1-19-g372bded -v "$PWD":/usr/src/myapp -w /usr/src/myapp rust cargo build --release
    Lloyd Konneker
    @bootchk
    • !Sh 'git clone --recurse-submodules git://github.com/flathub/org.gimp.GIMP' seems to create a directory org.gimp.GIMP at the top i.e. in parent directory of vagga.yaml, i.e. not in the container. That seems bad. I suppose I can do the recursion myself.
    Paul Colomiets
    @tailhook
    @bootchk, I've already answered on a github, but basically, just cd into a specific directory in the container (we don't forbid mutating working directory, as it would crash a lot of tools out of the box)
    Michael Pankov
    @mkpankov
    hey, from the docs I got the impression that I can build a container with vagga and run it with docker.
    is it correct? how do I do it?
    Paul Colomiets
    @tailhook
    @mkpankov, yes. You should be able to do something like vagga _pack_image CONTAINER_NAME > image.tar; docker import image.tar (or ADD image.tar / in Dockerfile)
    Michael Pankov
    @mkpankov
    thanks, not a docker user so it was really a riddle
    Michael Pankov
    @mkpankov
    hey
    I have several repos where I want to use vagga, currently I've put vagga.yaml in first one. now I've discovered I need to share parts of vagga.yaml between repos (i.e. definition of Rust container). how should I do that?
    I've read about YAML includes and mixins, I can't quite put it together. both of them are restricted to including stuff from sub-directories. why?
    Paul Colomiets
    @tailhook
    @mkpankov, this is a a security measure. So that when you run vagga xxx from a foreign project it can't stole your ssh keys or similar. You can share configs either but putting them in git submodule (and updating manually), or you can mount --bind a subdirectory into several places. Or you can use external-volumes to overcome that limiation (although, it would require configuring them for every user).
    Michael Pankov
    @mkpankov
    thanks for quick reply. to me that seems like a lot of overhead for something I'd like to have out-of-the-box. I mean, submodules are hell and mounting something manually when the purpose of vagga is to avoid doing that... what is your opinion on something that could be built-in?
    or, maybe I should just write a "root" vagga.yaml and move everything there? so that project repos don't contain one and come just as source repositories
    context is, I have repos of two rust tools, one of which runs the other, so they are almost always used together
    Paul Colomiets
    @tailhook
    Technically you can, if you like it.
    I usually install one tool in the second's vagga.yaml as a normal package (e.g. cargo install)
    And then if I want debug something very coupled I use mount --bind or just copy thing in ad hoc way.
    Alternatively, you can also make a command which fetches mixin remotely before the first start.
    Michael Pankov
    @mkpankov
    my tools are proprietary and we currently don't run our registry, so I can't cargo install
    I guess I'd like something of "best practice" advice (even better if it's in the docs)

    Alternatively, you can also make a command which fetches mixin remotely before the first start.

    that's interesting

    that way I can share my include/mixin w/o access to parent directory, could work, I think
    btw, are symlinks followed? If I ln -s ../include.yaml include.yaml?
    Paul Colomiets
    @tailhook
    No, that would kill whole security :)
    Michael Pankov
    @mkpankov
    yeah, thought so)
    Paul Colomiets
    @tailhook

    I'd like something of "best practice" advice

    I usually recommend as independent repos as possible, i.e. that you can vagga run in any one. And use git submodules for thing that can't be fetched from package repos. The big advantage of submodules that you can always mount --bind on top. Not sure it's anywhere in the docs.

    Michael Pankov
    @mkpankov
    what do you mean by "mount --bind on top"? like, why would I need it
    (sorry if it's stupid question, I'm a novice with containers)
    Paul Colomiets
    @tailhook
    I.e you have ./proj1 and ./proj2. And also ./proj1/proj2 is a git submodule. Sometimes you edited ./proj2 and want to try it inside ./proj1: cd proj1; mount --bind ../proj2 proj2 and you have it.
    https://medium.com/@paulcolomiets/announcing-vagga-0-7-1-85b9a9e84f2a
    Section "mixins" describes how to "generate" mixin (in your case 'generating' might be just fetching somewhere)
    Michael Pankov
    @mkpankov
    thanks, will try that
    Michael Pankov
    @mkpankov
    a side question: are you actively developing vagga currently?
    Paul Colomiets
    @tailhook
    @mkpankov, I don't have time recently, so we definitely have some technical debt (i.e. need to release a stable). But this is a thing that I'm using every day more that any other command-line tool (for obvious reasons :) ). And there are other people like me (hard to count). So I don't consider project abandoned. And I'm looking forward to spent more time on it.
    Michael Pankov
    @mkpankov
    hey. in case you have advices on how to debug this, I'd appreciate it
    tailhook/vagga#519
    Paul Colomiets
    @tailhook
    @mkpankov Answered in github issue. Hopefully, that is helpful
    Richard Gomes
    @frgomes
    Hello everyone. My first post here. I'm happy to find an alternative to Docker, to a certain extent. :-)
    Richard Gomes
    @frgomes
    I've tried to build from sources, following the instructions from vagga.readthedocs.org, employing tag v0.8.1 but I've got compilation errors.
    Am I doing anything wrong, please?
    #!/bin/bash
    
    sudo apt install musl-tools -y
    
    git clone https://github.com/tailhook/vagga
    cd vagga/
    git checkout v0.8.1
    rustup target add x86_64-unknown-linux-musl
    cargo build --target x86_64-unknown-linux-musl
    $ lsb_release -a
    No LSB modules are available.
    Distributor ID: Debian
    Description:    Debian GNU/Linux 10 (buster)
    Release:        10
    Codename:       buster
    
    $ uname -a
    Linux lua 5.3.0-0.bpo.2-amd64 #1 SMP Debian 5.3.9-2~bpo10+1 (2019-11-13) x86_64 GNU/Linux
    Richard Gomes
    @frgomes
    error: environment variable `VAGGA_VERSION` not defined
      --> src/config/config.rs:56:26
       |
    56 |         .current_version(env!("VAGGA_VERSION").to_string()))
       |                          ^^^^^^^^^^^^^^^^^^^^^
    
    error: environment variable `VAGGA_VERSION` not defined
      --> src/launcher/mod.rs:94:19
       |
    94 |             Print(env!("VAGGA_VERSION").to_string()),
    The documentation does not mention anything about VAGGA_VERSION, as far as I read. And I didn't read much... just jumped to Installation and followed instructions.
    Richard Gomes
    @frgomes
    OK.
    VAGGA_VERSION=$(git describe) cargo build --target x86_64-unknown-linux-musl