Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

test: Build source package in VM #3197

Closed

Conversation

Projects
None yet
3 participants
@mvollmer
Copy link
Member

commented Nov 20, 2015

This avoids using OS specific tools on the testing host.

Note that we don't spawn a dedicated VM just to build the source package, this happens as part of vm-build and vm-create runs.

@mvollmer mvollmer added the needswork label Nov 20, 2015

@stefwalter

This comment has been minimized.

Copy link
Contributor

commented Nov 20, 2015

I don't think this will work for @sgallagher who uses make-srpms as a quick way to get the tree to build elsewhere.

@mvollmer mvollmer force-pushed the mvollmer:test-source-package-in-vm branch from e8e67ba to 2e69e1e Nov 20, 2015

@mvollmer

This comment has been minimized.

Copy link
Member Author

commented Nov 20, 2015

We can keep tools/make-srpm, of course.

@mvollmer mvollmer force-pushed the mvollmer:test-source-package-in-vm branch 2 times, most recently from 10de660 to b4148d4 Nov 20, 2015

@mvollmer mvollmer changed the title WIP - test: Build source package in VM test: Build source package in VM Nov 20, 2015

@@ -31,20 +31,17 @@ args = parser.parse_args()

def build(machine):
"""Build Cockpit in a virtual machine"""
srpm = subprocess.check_output([ "../tools/make-srpm" ]).strip()
source = subprocess.check_output([ "../tools/make-tar" ]).strip()

This comment has been minimized.

Copy link
@stefwalter

stefwalter Nov 20, 2015

Contributor

Can we call this script 'make-source' to match the nomenclature you've used throughout all the other various and stuff. It also helps distinguish it from a real tarball (which is created via 'make dist').

This comment has been minimized.

Copy link
@mvollmer

mvollmer Nov 23, 2015

Author Member

Done.

machine.execute('su - builder -c "%s"' % mock_cmd)
machine.download_dir("/var/tmp/mock", "mock")
machine.upload([ "guest/lib" ], "/usr/lib/testvm")
machine.upload([ source, "./guest/%s.build-source" % machine.os ], "/var/tmp")

This comment has been minimized.

Copy link
@stefwalter

stefwalter Nov 20, 2015

Contributor

Why does this need an OS specific name?

This comment has been minimized.

Copy link
@mvollmer

mvollmer Nov 23, 2015

Author Member

The script will be different for different OSes, like Debian.

# First make a .tar.gz with the source code
(
cd $base/..
srpm=$(cd ${rpm_tmpdir} && "$base/../test/guest/lib/make-srpm" $("$base/make-tar"))

This comment has been minimized.

Copy link
@stefwalter

stefwalter Nov 20, 2015

Contributor

I would suggest disentangling this a bit, and calling make-tar (or make-source) on a prior line.

This comment has been minimized.

Copy link
@mvollmer

mvollmer Nov 23, 2015

Author Member

Done.

@mvollmer

This comment has been minimized.

Copy link
Member Author

commented Nov 20, 2015

The build-results are not copied when the build fails.

@mvollmer

This comment has been minimized.

Copy link
Member Author

commented Nov 20, 2015

I think I'll merge vm-build into vm-install here.

@stefwalter

This comment has been minimized.

Copy link
Contributor

commented Nov 20, 2015

I think I'll merge vm-build into vm-install here.

Makes sense

@mvollmer mvollmer force-pushed the mvollmer:test-source-package-in-vm branch from b4148d4 to 2abe56f Nov 20, 2015

@mvollmer

This comment has been minimized.

Copy link
Member Author

commented Nov 20, 2015

The build-results are not copied when the build fails.

Fixed.

@mvollmer mvollmer referenced this pull request Nov 20, 2015

Closed

Debian #3202

@mvollmer mvollmer force-pushed the mvollmer:test-source-package-in-vm branch 3 times, most recently from 0e18e12 to 037dd53 Nov 23, 2015

@mvollmer

This comment has been minimized.

Copy link
Member Author

commented Nov 23, 2015

I think I'll merge vm-build into vm-install here.

Done, but fedora-atomic is not yet supported.

@mvollmer

This comment has been minimized.

Copy link
Member Author

commented Nov 23, 2015

New fedora-testing image is missing.

@mvollmer mvollmer force-pushed the mvollmer:test-source-package-in-vm branch 2 times, most recently from 42aedc5 to 7fedc71 Nov 23, 2015

@mvollmer

This comment has been minimized.

Copy link
Member Author

commented Nov 23, 2015

New fedora-testing image is missing.

Uploaded.

@mvollmer mvollmer force-pushed the mvollmer:test-source-package-in-vm branch 2 times, most recently from 1a8cae3 to bc0c2f6 Nov 23, 2015

@mvollmer

This comment has been minimized.

Copy link
Member Author

commented Nov 26, 2015

Done, but fedora-atomic is not yet supported.

Fixed.

@mvollmer mvollmer removed the needswork label Nov 26, 2015

@mvollmer

This comment has been minimized.

Copy link
Member Author

commented Nov 26, 2015

The fedora-atomic and fedora-testing failures are very likely unrelated. Building and installing seem to work for both configurations.

@stefwalter

This comment has been minimized.

Copy link
Contributor

commented Nov 27, 2015

Needs rebase.

mvollmer added some commits Nov 20, 2015

test: Make guest/lib available in VM
During image creation and package building, so that the scripts can
share the hairy bits.
test: Build and install in the same VM
And make the source package in that same VM as well.  For
fedora-atomic, building and installing happens in different VMs.

@mvollmer mvollmer force-pushed the mvollmer:test-source-package-in-vm branch from bc0c2f6 to 5b27948 Nov 27, 2015

@mvollmer

This comment has been minimized.

Copy link
Member Author

commented Nov 27, 2015

Needs rebase.

Done.

@mvollmer mvollmer removed the needswork label Nov 27, 2015

@mvollmer mvollmer closed this in 02aa98e Nov 27, 2015

@akilawickey

This comment has been minimized.

Copy link

commented Mar 25, 2016

i got the following when i run cockpit on fedora 23 vm

[akilawickey@asak-opensource cockpit]$ sudo vagrant destroy
==> default: Remove stale volume...
==> default: Domain is not created. Please run vagrant up first.
[akilawickey@asak-opensource cockpit]$ sudo vagrant up
Bringing machine 'default' up with 'libvirt' provider...
==> default: Creating image (snapshot of base box volume).
==> default: Creating domain with the following settings...
==> default: -- Name: cockpit_default
==> default: -- Domain type: kvm
==> default: -- Cpus: 1
==> default: -- Memory: 1024M
==> default: -- Management MAC:
==> default: -- Loader:
==> default: -- Base box: fedora-23-cloud-base
==> default: -- Storage pool: default
==> default: -- Image: /var/lib/libvirt/images/cockpit_default.img (41G)
==> default: -- Volume Cache: default
==> default: -- Kernel:
==> default: -- Initrd:
==> default: -- Graphics Type: vnc
==> default: -- Graphics Port: 5900
==> default: -- Graphics IP: 127.0.0.1
==> default: -- Graphics Password: Not defined
==> default: -- Video Type: cirrus
==> default: -- Video VRAM: 9216
==> default: -- Keymap: en-us
==> default: -- INPUT: type=mouse, bus=ps2
==> default: -- Command line :
Error while creating domain: Error saving the server: Call to virDomainDefineXML failed: invalid argument: could not find capabilities for domaintype=kvm

@stefwalter

This comment has been minimized.

Copy link
Contributor

commented Mar 25, 2016

@akilawickey This is an odd place to startup a discussion. In an old unrelated bug.

That said, you probably need to install qemu-kvm and qemu-system-x86

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.