IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
When running `vagrant ssh-config` from ansible, Vagrant for some reason
still wants to execute the File.write() operation, but fails to do so
because the $PWD is $topsrcdir/vagrant, in which .vagrant does not
exist.
Switch to using the absolute path.
Closes: #555
Approved by: cgwalters
This is just the final bit required to make sure the vagrant and
non-vagrant paths can work happily together. It's mostly minor fixes,
though the most major change which also affects vagrant is that we now
sync to the root home dir, rather than ~vagrant.
Closes: #524
Approved by: cgwalters
We further split libvm from vagrant. It no longer does 'vagrant
ssh-config'. Instead, it always assumes that an ssh-config is provided.
We now have complete separation of libvm from vagrant.
We change the ansible provisioner as follows:
- Allow passing in a VAGRANT_BOX env var to override the default
CentOS box.
- No longer assume that the root user account is unlocked and has a
valid 'vagrant' password. This worked for the centos box but isn't
sure to work on every box. Instead, we now just run ansible as the
default vagrant user, and during provisioning set up the root
account and generate an ssh-config so that libvm can connect
directly as root.
- No longer build the buildimg during provisioning. This actually
stopped working a while ago since the default rsync is disabled. We
can just let the buildimg get created on the first compilation. In
practice, the bigger issue isn't creating the buildimg, but being
able to easily update the host and buildimg pkgs.
Closes: #516
Approved by: jlebon
For the regular hack/build/test cycles, creating a new deployment each
time becomes overkill. We add a new `make vmoverlay` target which
directly overlays the newly built binaries on an unlocked system.
We also make rsync smarter so that we can afford to not `make clean`
everytime while still allowing the host's repo to be fully configured.
Closes: #360
Approved by: cgwalters
By far the longest step in provisioning a new VM is the building of the
container. This helps alleviate things a little by caching it on the
host. It's not a complete solution however. We also need to make it easy
to update an existing container.
Closes: #344
Approved by: cgwalters
From Vagrantfile:
It's just easier to have ssh set up as root from the start so that tests
don't need to sudo, which can sometimes cause issues. If we need to test
any unprivileged things, we can still just sudo back into the vagrant
user.
Closes: #344
Approved by: cgwalters
Add a HACKING.md document detailing how to get started and test
rpm-ostree using the vagrant box.
Fix the CONTRIBUTING.md link and add a link to HACKING.md in README.md.
Closes: #344
Approved by: cgwalters
In order for vmcheck to be useful for testing, we need the machine to be
in a "clean" state. That is, sitting on a commit, ready for being
manipulated.
This is a small step towards this goal. Instead of overwriting the
files, we use rofiles-fuse to safely install and create a new
deployment.
Closes: #321
Approved by: cgwalters
I was running out of RAM doing builds in the VM with just 512MB.
I think for single host machines, we can assume a lot of RAM.
If one is doing multi-node Vagrant that's a different thing.
Also update the comment at the top.
Closes: #313
Approved by: jlebon
This is infrastructure that's oriented around Vagrant, we do builds
inside the target VM (actually inside a Docker container), but then
directly `make install DESTDIR=/host/`.
The goal here is to have a convenient workflow for:
- dev -> hand testing
- dev -> run destructive tests
Closes: #303
Approved by: jlebon
Because this now works:
```
ostree remote add --set=gpg-verify=false centos-atomic-continuous https://ci.centos.org/artifacts/sig-atomic/rdgo/centos-continuous/ostree/repo/
rpm-ostree rebase centos-atomic-continuous:centos-atomic-host/7/x86_64/devel/continuous
```
In the future we'll need infra to switch between Fedora and CentOS for
dev, but for now, I think we should focus on CentOS becuase it has to
work in order to produce downstream work.
Closes: #283
Approved by: giuseppe
