gitlab-runner merge requestshttps://staging.gitlab.com/gitlab-org/gitlab-runner/-/merge_requests2017-08-02T18:44:17Zhttps://staging.gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/313Force-terminate VirtualBox and Parallels VMs so snapshot restore works properly2017-08-02T18:44:17Zusername-removed-534635Force-terminate VirtualBox and Parallels VMs so snapshot restore works properly## What does this MR do?
Forcibly terminates the target VM, even if the guest OS is uncooperative. The implementation of `Kill` is changed to forcibly (and synchronously) stop the target VM. `Stop` is no longer required.
Should res...## What does this MR do?
Forcibly terminates the target VM, even if the guest OS is uncooperative. The implementation of `Kill` is changed to forcibly (and synchronously) stop the target VM. `Stop` is no longer required.
Should resolve #1356 and #1279.
## Why was this MR needed?
Version 1.5.3 fails to delete the created VM if the guest OS ignores the ACPI power button signal (`VBoxManage controlvm <vm> acpipowerbutton`). For example, OS X 10.11 only pops up a dialog to shut down / restart. `VBoxManage` (VirtualBox 5.1.4) will not delete a running VM, and fails with the following error:
~~~
VBoxManage: error: Cannot unregister the machine 'testvm' while it is locked
VBoxManage: error: Details: code VBOX_E_INVALID_OBJECT_STATE (0x80bb0007), component MachineWrap, interface IMachine, callee nsISupports
VBoxManage: error: Context: "Unregister(CleanupMode_DetachAllReturnHardDisksOnly, ComSafeArrayAsOutParam(aMedia))" at line 155 of file VBoxManageMisc.cpp
~~~
As of 1.5.3, the `virtualbox` executor has two different ways of killing a VM: `vbox.Stop` and `vbox.Kill`. Currently `Kill` sends the power button signal while `Stop` forcibly stops via `VBoxManage controlvm <vm> poweroff`. (These meanings are backwards, which the MR resolves by removing `Stop` and changing the behavior of `Kill`.) However, there is actually no reason to perform a graceful shutdown under any circumstances. Consider the two modes of operation:
- Snapshots disabled (`disable_snapshots = true`)
1. Executor clones new target VM from base VM (optionally from a live or cold snapshot)
2. Build runs
3. Executor deletes target VM (must not be running)
- Snapshots enabled (`disable_snapshots = false`)
1. If target VM does not already exist and have a snapshot:
1. Executor clones new target VM from base VM
2. Wait until SSH comes up
3. Live snapshot of target VM taken
2. Restore target VM from previously created live snapshot
- (If restore fails because target VM is already running, destroy it and start over)
3. Build runs
4. Shut down target VM in preparation for next build
In either case, there is no situation in which the target VM is not either freshly cloned or restored from a live snapshot. So performing a graceful shutdown is pointless.
The same issue applies to the Parallels executor, which uses an identical workflow to the VirtualBox executor.
## Are there points in the code the reviewer needs to double check?
None.
## Does this MR meet the acceptance criteria?
- [ ] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/master/CHANGELOG.md) entry added (I assume this will happen in next release)
- [ ] Documentation created/updated (N/A)
- Tests
- [ ] Added for this feature/bug (N/A)
- [x] All builds are passing
- [x] Branch has no merge conflicts with `master` (if you do - rebase it please)
v1.9https://staging.gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/589Fix VirtualBox and Parallels executors registration bugs2017-07-04T13:44:11Zusername-removed-20549Fix VirtualBox and Parallels executors registration bugs## What does this MR do?
Fix virtualbox executor registration bug.
## Why was this MR needed?
Registration virtualbox executor runner by non-interactive, Don't write ssh settings.
```
$ gitlab-ci-multi-runner register \
-u ...## What does this MR do?
Fix virtualbox executor registration bug.
## Why was this MR needed?
Registration virtualbox executor runner by non-interactive, Don't write ssh settings.
```
$ gitlab-ci-multi-runner register \
-u http://gitlab.example.com/ci \
-r xxxxxx \
--tag-list foo \
--executor virtualbox \
--ssh-user abc \
--ssh-host foo.bar \
--virtualbox-base-name vbox1 \
-n
```
```
concurrent = 1
check_interval = 0
[[runners]]
name = "vanp"
url = "http://gitlab.example.com/ci"
token = "d703f5b1acc01233de252cbd4fbe7f"
executor = "virtualbox"
[runners.cache]
```
## Are there points in the code the reviewer needs to double check?
## Does this MR meet the acceptance criteria?
- [ ] Documentation created/updated
- Tests
- [ ] Added for this feature/bug
- [ ] All builds are passing
- [ ] Branch has no merge conflicts with `master` (if you do - rebase it please)
## What are the relevant issue numbers?
Tries to resolve #2120.v1.11