@@ -25,7 +25,16 @@ git submodule add https://github.com/rust-vmm/rust-vmm-ci.git
25
25
git commit -s -m " Added rust-vmm-ci as submodule"
26
26
```
27
27
28
- 2 . Create the coverage test configuration file named
28
+ 2 . Run the initial setup script for configuring dependabot for automated cargo
29
+ and submodule updates, as well as configuring which hardware platforms CI
30
+ should be run for:
31
+
32
+ ``` bash
33
+ # Script has to be run relative to the repository root!
34
+ ./rust-vmm-ci/setup_repository.sh
35
+ ```
36
+
37
+ 3 . Create the coverage test configuration file named
29
38
` coverage_config_ARCH.json ` in the root of the repository, where ` ARCH ` is the
30
39
architecture of the machine.
31
40
There are two coverage test configuration files, one per each platform.
@@ -55,14 +64,6 @@ Additionally, the following optional fields are available:
55
64
This file is required for the coverage integration so it needs to be added
56
65
to the repository as well.
57
66
58
- 3 . Copy one of the two provided dependabot configurations to ` .github/dependabot.yml ` ,
59
- e.g. run ` cp rust-vmm-ci/dependabot-{weekly,monthly}.yml .github/dependabot.yml ` .
60
- Note that just symlinking the file does not work, as dependabot will not
61
- follow symlinks into submodules. This means that updates to these files made in
62
- rust-vmm-ci will need to be manually consumed for now. We recommend setting up
63
- weekly dependabot updates only if the crate receives multiple contributions a week,
64
- and if you expect to have the bandwidth to address weekly dependency PRs.
65
-
66
67
4 . Create a new pipeline definition in Buildkite. For this step ask one of the
67
68
rust-vmm Buildkite [ admins] ( CODEOWNERS ) to create one for you. The process is explained
68
69
[ here] ( https://github.com/rust-vmm/community/blob/main/docs/setup_new_repo.md#set-up-ci ) .
@@ -119,24 +120,7 @@ For most use cases, overriding or extending the configuration is not necessary.
119
120
want to do so if, for example, the platform needs a custom device that is not available
120
121
on the existing test instances or if we need a specialized hypervisor.
121
122
122
- 6 . Tests will be running on ` x86_64 ` and ` aarch64 ` platforms by default. To change
123
- this, e.g. to enable other experimental platforms like ` riscv64 ` , a ` .platform `
124
- file can be included in the repository root. This file documents what platforms
125
- are to be enabled for the repository.
126
-
127
- If ` .platform ` file is provided, it will be strictly observed. In ` .platform `
128
- file, each platform are separated by newline character. Currently, we support
129
- ` x86_64 ` , ` aarch64 ` and ` riscv64 ` platforms.
130
-
131
- For example, we can enable tests to be run on ` riscv64 ` platform in addition to
132
- ` x86_64 ` and ` aarch64 ` by:
133
- ```
134
- x86_64
135
- aarch64
136
- riscv64
137
- ```
138
-
139
- 7 . The code owners of the repository will have to setup a WebHook for
123
+ 6 . The code owners of the repository will have to setup a WebHook for
140
124
triggering the CI on
141
125
[ pull request] ( https://developer.github.com/v3/activity/events/types/#pullrequestevent )
142
126
and [ push] ( https://developer.github.com/v3/activity/events/types/#pushevent )
@@ -148,7 +132,9 @@ The [Buildkite](https://buildkite.com) pipeline is the definition of tests to
148
132
be run as part of the CI. It includes steps for running unit tests and linters
149
133
(including coding style checks), and computing the coverage.
150
134
151
- Currently the tests can run on Linux ` x86_64 ` and ` aarch64 ` hosts.
135
+ Currently the tests can run on Linux ` x86_64 ` , ` aarch64 ` and ` riscv64 `
136
+ (virtualized inside QEMU) hosts. Which hosts tests should be ran for is
137
+ determined by the ` .platform ` file in the repository root.
152
138
153
139
Example of step that checks the build:
154
140
0 commit comments