- User Facing CI
ci:run- Run Testsci:ready_to_merge- Send To Merge Queue
- Manually Running Tests
- Sync From Tensorflow Repository
- Merge Queue Details
The continuous integration system is controlled by applying labels to PRs. There are only two important labels: ci:run runs the testing suite, and ci:ready_to_merge places a PR in the merge queue.
The ci:run label runs the main testing suite against the PR. For details of the tests involved, examine the linked file. The ci:run tag is self-removing.
After all tests from ci:run have passed, the Google CLA has been agreed to, and a reviewer has approved the PR, applying the ci:ready_to_merge label will enter the PR into the merge queue. Unless there is a conflict with other PR's in the queue, this should be a fire and forget operation. In the case of a conflict due to code that is merged before a given PR, you will need to troubleshoot your code manually.
Tests can also be run manually on the command line within a docker container, which can be built with:
docker build -t tflm-ci -f ci/Dockerfile.micro .
or use the tflm-ci docker image from here.
You will still need to copy or mount your fork of tflite-micro on to this docker container prior to running any tests. To run the built Docker image interactively and mount your local copy of tflite-micro on the container, run:
docker run -v /path/to/local/tflite-micro:/path/to/docker/tflite-micro -it tflm-ci /bin/bash
This way changes from your local fork will be reflected in the Docker container.
You can also view or remove your instantiated containers by doing:
docker ps --all
docker rm <docker image ID>
While TfLite Micro and TfLite are in separate GitHub repositories, the two projects continue to share common code.
The TensorFlow repo is the single source of truth for this shared code. As a result, any changes to this shared code must be made in the TensorFlow repo which will then automatically sync'd via a scheduled GitHub workflow.
This section is probably only of interest if you plan to be doing surgery on the CI system.
We use Mergify for our merge queue. The documentation is reasonably straight forward.
Our mergify.yml is fairly standard. It triggers on ci:ready_to_merge label and requires all branch protection checks to pass before a PR can be added to the queue. When the PR is merged it removes the label.
The one slightly complicated wrinkle in our system is the test suite being run only when the ci:run label is applied. As soon as the tests are run, the label is removed.
As the queue processes each PR, it creates a temporary branch and merges in the results of the previous passing PRs my merging main. This merge resets all the test results, so the ci:run tag must be reapplied in queue.