|M1||Planning, Handover and Deployment|
SOW and project plan
Hand over from OCE to Developer Services
Project Plan & SoW Reviewed. Meetings have been held and follow on meetings will occur as normal course of the project
|M2||Arm CI Jobs migration - CR-01|
Arm CI Jobs migration (6217, 6384, 6416, 6417, 6217, 6466)
FVP Support (TF-M ID3, TF-A ID26)
FVP models running CI jobs (LSS-1393, 5180, CR-01)
Staging Scripts (TF-M ID7, TF-A ID7)
A staging version of the scripts created on the production instance (LSS-1430)
Ability to build multiple configurations of TF-A (TF-A ID9, tf-a-job-configs/4917 superseded by CR-01)
Provide a way to re-trigger the jobs manually (TF-A ID3, LSS-1470)
Ability to specify at run time that a CI job should keep all artifacts indefinitely. (TF-A ID22 LSS-1485)
TF-A Static Analysis Integration (TF-A ID17, TF-A ID19)
Arm check scripts (4938 superseded by CR-01)
cppcheck (4938 superseded by CR-01)
Coverity Free online check (4938 superseded by CR-01)
TF-M Static Analysis Integration (TF-M ID1)
Arm check scripts (4973, 4972)
Coverity Free online check (tf-m-ci-scripts/5293)
|M3 & M4||TF-A Tests|
Create CI loop for TF-A Tests (TF-A ID2, 4873 superseded by CR-01)
Ability to build multiple configurations of TF-A Tests (TF-A ID12, 4917 superseded by CR-01)
CI results for TF-A and TF-TF must stay available for a minimum duration (eg. 1 week) (TF-A ID21)
Run TF-TF tests "bare metal" on FVP (TF-A ID24 5180 superseded by CR-01)
Provide facility for a job to pass the "level" of testing required, eg. minimal, full, etc., where different tests are executed depending on the level passed into (TF-M ID10, TF-A ID31, CR-01)
|M5|| Specify FVP Versions (TF-A ID13)|
- Update FVP support to host multiple versions of models
- Allow jobs to specify which version of FVP models are used
Compilers accessed in the docker containers
Ability to integrate alternative compilers into builds (TF-M ID9, TF-A ID10 ) dockerfiles/+/5454
Ability to use different versions of a compiler for builds (TF-A ID11)
Integrate one alternative compiler and have two versions of the standard Arm GCC compiler to demonstrate how the functionality works. Compilers should be secure, preventing users from accessing them directly, and should only be used for building TF CI jobs
|M6, M7 & M8|| Musca A/B1 Support (TF-M ID5)|
Musca B1 board installed in Linaro Cambridge LAVA lab.
Musca B1 board support integrated into the CI loop.
Dashboard configured in SQUAD instance (TF-M ID2, TF-A ID32)
Metrics and test results from LAVA jobs visible in the SQUAD dashboard
Deploy HTML Reports (TF-A ID23)
Deliver ongoing Linaro internal work to produce HTML reports from SQUAD data
Boot Results passed to Gerrit (No ID)
Use the LAVA notification service to pass boot results back to the review that triggered the job(s)
QEMU Support (TF-M ID4)
Integrate the QEMU SSE-200 v8m machine into the CI loop.
|Musca A removed and S1 on hold for Phase 3 (per 7/2 Meeting).|
|M9||Integrate PSA compliance tests (TF-M ID6)|
- Provide a build option to run PSA API tests
- Ensures patches will not break PSA compliance
|Milestone Timeboxed to 20 days /per Dec Board Approval|
|M10||Modularise Build and Test Process|
- Remove all configuration out of the scripts and into the YAML provided to control the job. (TF-M ID14)
- Allow the user to trigger a job with default, custom or release parameters. This gives limited permissions to the user to create jobs. (TF-M ID18)
|Milestone removed /per Dec Board approval|
|M11||Documentation and User Guide (TF-M ID8)|
- How to use the complete CI loop
- How to integrate a new platform, including boards in a LAVA Federated lab
- How to deploy your own instance
|Milestone Timeboxed to 10 days /per Dec Board Approval|
|New||Request to add Rich Text Plugin for Jenkins |
- Used to navigate CI status, artifacts and results.
- Fill in the drop down boxes:
- Project: LAB & System Software (LSS)
- Issue Type: Ticket
- Click Next
- Fill in the required details
- Summary: You should fill in the "Summary" with a snappy title. I've started to prefix my titles with "TF CI: " to help identify them in the list of issues.
- Components: "Systems (Bugzilla, Git, Gerrit, Jenkins)"
- Client Stakeholder: "Trusted-Firmware"
- Fill in the issue Description
- You will need to fill in the Description, even if you think the title is sufficient. Provide enough overview detail so the issue is clear to understand by management, but make sure you include all the technical details you need for the support engineer to reproduce and resolve your problem.
- Click the "Create" button at the bottom of the page
- Add Watchers
- It's probably a good idea to add Bill Fletcher and Ryan Harkin to the Watchers on the ticket.
If you are unable to create a ticket or have issues, you may need Jira access setup. Please contact: Glen (email@example.com) or Bill (firstname.lastname@example.org) or Ryan (email@example.com)
I agree that this wont be part of phase 2. I just wanted to know how this would scale up for more platforms and if there is any room for platforms to increase scanners and rules.
For Tegra platforms, at least, we use CERT and CCM scanners. We also enable more MISRA rules than TF-A. I'm glad that we will have the freedom to enable them with OpenCI at some point.