4.2 KiB
Cockpit Bots
These are automated bots and tools that work on Cockpit. This includes updating operating system images, testing changes, releasing Cockpit and more.
Images
In order to test Cockpit-related projects, they are staged into an operating
system image. These images are tracked in the bots/images directory.
These well known image names are expected to contain no .
characters and have no file name extension.
For managing these images:
- image-download: Download test images
- image-upload: Upload test images
- image-create: Create test machine images
- image-customize: Generic tool to install packages, upload files, or run commands in a test machine image
- image-prepare: Build and install Cockpit packages into a test machine image (specific to the cockpit project itself, thus it is in test/, not bots/)
For debugging the images:
- bots/vm-run: Run a test machine image
- bots/vm-reset: Remove all overlays from image-customize, image-prepare, etc from test/images/
In case of qemu-system-x86_64: -netdev bridge,br=cockpit1,id=bridge0: bridge helper failed
error, please allow qemu-bridge-helper to access the bridge settings.
To check when images will automatically be refreshed by the bots use the image-trigger tool:
$ bots/image-trigger -vd
Tests
The bots automatically run the tests as needed on pull requests and branches. To check when and where tests will be run, use the tests-scan tool:
$ bots/tests-scan -vd
Note on eslintrc interaction
As eslint looks for additional configurations, eslintrc.(json|yaml) files, in
parent directories, it is recommended to have "root": true in the eslint
configuration of any project which is using eslint and is tested through
cockpit-bots.
Integration with GitHub
A number of machines are watching our GitHub repository and are executing tests for pull requests as well as making new images.
Most of this happens automatically, but you can influence their actions with the tests-trigger utility in this directory.
Setup
You need a GitHub token in ~/.config/github-token. You can create one for your account at
https://github.com/settings/tokens
When generating a new personal access token, the scope only needs to encompass public_repo (or repo if you're accessing a private repo).
Retrying a failed test
If you want to run the "verify/fedora-atomic" testsuite again for pull request #1234, run tests-trigger like so:
$ bots/tests-trigger 1234 verify/fedora-atomic
Testing a pull request by a non-whitelisted user
If you want to run all tests on pull request #1234 that has been opened by someone who is not in our white-list, run tests-trigger like so:
$ bots/tests-trigger -f 1234
Of course, you should make sure that the pull request is proper and doesn't execute evil code during tests.
Refreshing a test image
Test images are refreshed automatically once per week, and even if the last refresh has failed, the machines wait one week before trying again.
If you want the machines to refresh the fedora-atomic image immediately, run image-trigger like so:
$ bots/image-trigger fedora-atomic
Creating new images for a pull request
If as part of some new feature you need to change the content of some or all images, you can ask the machines to create those images.
If you want to have a new fedora-atomic image for pull request #1234, add a bullet point to that pull request's description like so, and add the "bot" label to the pull request.
* [ ] image-refresh fedora-atomic
The machines will post comments to the pull request about their progress and at the end there will be links to commits with the new images. You can then include these commits into the pull request in any way you like.
If you are certain about the changes to the images, it is probably a good idea to make a dedicated pull request just for the images. That pull request can then hopefully be merged to master faster. If instead the images are created on the main feature pull request and sit there for a long time, they might cause annoying merge conflicts.