View source for CI/CD

From DDCIDeos
You do not have permission to edit this page, for the following reason:
The action you have requested is limited to users in the group: Users.
You can view and copy the source of this page.
= CI/CD Meeting Details = 
Wed, 1:30pm MDT <br>
[https://teams.microsoft.com/l/meetup-join/19%3ameeting_NzY4MjM5YzktMDk5MC00NWFjLTgyYTMtYzgyYTRmOWM2MGVm%40thread.v2/0?context=%7b%22Tid%22%3a%22a5b5ff18-fc5f-4e46-a561-9cc553c3770a%22%2c%22Oid%22%3a%22281fc605-0271-4cd1-9c28-10edd3148d1e%22%7d Teams Meeting Link] <br>
Meeting ID: 244 603 111 788 3 <br>
Dial in by phone <br>
+1 323-618-1547,,440892883# United States, Los Angeles <br>
Phone conference ID: 440 892 883#

== Important Links ==
* [https://deos.ddci.com/svn/DDCI/maintainer-tools/cicd CI/CD scripts and support files]
* [https://deos.ddci.com/svn/DDCI/maintainer-tools/cicd/build-results.htm Latest Build Summary]
* [https://nx3000.ddci.com/cicdTestResults/results/ Latest Build Artifacts] Note: Sometimes give an error page, refresh usually clears this error
* [https://deos.ddci.com/ddciWiki/Planning_Documents#Open_Tooling_Updates Open Tooling PCRs] These open PCRs may relate to tooling updates required for CI/CD.
* [http://jenkins.ddci.com:8080/ Local Jenkins]
** To Login: Username: $USER@ddci.com   Password is the Active Directory password.

== Meeting Notes ==
Note: The CI/CD topic has been part of the AI Strategy Team meetings and the meeting notes are on that page.<br>
[https://deos.ddci.com/ddciWiki/AI_Strategy_Team#Meeting_Notes Link to Meeting Notes]
==2025==
===Next Meeting Topics===
*"Building on the built-in node can be a security issue. You should set up distributed builds. See the documentation." warning

===10-Dec-2025===
# Andre: Working with CI/CD team to get Coverity integrated into Jenkins' component builds.

===12-Nov-2025===
# CP: Demo'd the WIP updates being made to vfile to support Jenkins CI/CD integration. 
#* Updates to cygwin2deos.py and new inclusion of jenkins.yml file in each component to support these updates.
# GeekFest Presentation
#* Focus on "what was done", "what is being done", and "what is going to be done"
#** Shayne: CI/CD Overview & Python Scripting
#** Peter: Python
#** Evren: Regress
#** Matthew: Jenkins
#** Kenny: OpenArbor
#** TBD: Looking forward, future features, etc


===5-Nov-2025===
# PZ: We need a way to invoke instrumented/instrumented_optimized builds of components for automated build and testing (as needed and/or regularly recurring)
#* Not all components have these variants enabled in the configure.ac, is there a build-utils way to bypass this? How does OpenArbor do it?
#* This would be useful for abc-tool testing, maintenance, and enhancement; and for proactively checking the verification readiness (structural coverage) of any component or set of components.
#* Change local checkout of configure.ac to enable these variants?
# SS/EG: Intern task to make a web interface for the CSV? Can enable engineers to enable/disable their builds, add dependencies, etc...
# MC: Add a component build using the python script to the Jenkins server.
# Set up Jenkins so team leads/engineers themselves can go into Jenkins and add/remove/modify jobs. Jenkins jobs will have the component name, SVN URL, etc.

===15-Oct-2025===
# Evren and Shayne: working on script to run under Jenkins user

===08-Oct-2025===
# Andre: joined to discuss adding Coverity to the CI/CD script
# Evren and Shayne: working on script to run qemus
#* Issue starting qemu from the script due to qemu start script requiring a graphics console; Aaron to help out

===01-Oct-2025===
# Evren and Shayne: working on script to run qemus
# Shayne and Aaron: build-utils generates a file during the build that captures the component's subversion location on the ftp server(see notes from 24-Sept)
#* configure.ac file provides location of the component on the ftp server (useful when looking for stable or unreleased components)
#* Starting point: BDU script identifies unreleased components; these should be built from Head 
# Aaron: create the CI/CD infrastructure without policies; policies will be added as necessary; eg. custom BDU script(s)

===24-Sept-2025===
# Richard: Database for querying information on each component:
#* Shayne: Need to make the build consistent across components; eg. common location for current version../branches/mainline 
#* Adina: Which customers are using the component
#* Database options: 
#*# sqlite: Can it handle concurrent access?
#*# Other options?
# Shayne: Open Tooling PCR List related to Planning Docs (game launching checklist based on desired versions)
#* Planning CCB is needed (Peter!)
# GeekFest Presentation
#* From Richard: "At GeekFest I would like a presentation on what we've done in terms of CI/CD and what's on the short/long term roadmap for extending it. We'll have to decide based on roadmap needs if we need extra time in that session or a breakout to get ideas for implementing the extended features."
# Nightly build script: runs if components are updated; Peter to add abc-tool
# Evren: prototype of script is running on qemus
# Kenny: looking into automating the test harness runs

===27-Aug-2025===
* CI/CD Script
*# For Sept, the plan is for a mini tsunami with a very limited set of components: uart-zus (zcu102-aarch64), xilinx-gem (nai-ultrascale)
*#* bdu64sales - in progress to build the Docker image on the Jenkins machine; will require OA team to manually install the DDS and kick off the platform integration testing
*# Evren: working on kicking off regress testing 

===06-Aug-2025===
* CI/CD Script
*# Peter: cicd_build_components.csv file was not committed to svn last night; Shayne will research the issue - likely caused by file not being up-to-date
*# Evren: can start working on kicking off regress testing 

===30-Jul-2025===
* CI/CD Script
*# Shayne: working out script issues for environment variables not being defined
*# Peter: add check for updates, and only build components that have been modified; this includes externals
*# Evren: can start working on regress testing
* Addressing the abc failures - check for existence of an instrument script on components locked down on older build utils
*# short-term (complete): Shayne: add dummy instrument file to the CI/CD script
*# long-term: update externals on each component for build utils
* Shayne: move the script/files to the permanent location: https://deos.ddci.com/svn/DDCI/maintainer-tools/ci-cd/branches/mainline
*# Create a component in public bugzilla

===23-Jul-2025===
* CI/CD failure messages related to abc instrumented
*# Failure messages include a zipped build log and a link to the build log on nx3000
* CI/CD Script
*# Done for build objective
*# Peter: add check for updates, and only build components that have been modified; this includes externals
*# Evren: can start working on regress testing
* Addressing the abc failures - check for existence of an instrument script on components locked down on older build utils
*# short-term: Shayne: add dummy instrument file to the CI/CD script
*# long-term: update externals on each component for build utils
* Shayne: move the script/files to the permanent location: https://deos.ddci.com/svn/DDCI/maintainer-tools/ci-cd/branches/mainline
*# Create a component in public bugzilla

=Continuous Integration=
*Automatically build components as changes are committed to the repository
*Confirm that the build is not broken
*Notification of results (pass or fail)
**Emails to team (or team leads), and to committer of most recent changes if the build fails

==Continuous Testing==
*Run automated tests on components when the build passes as part of the continuous integration process
*Testing could be set up to precede the automated unrelease
*Levels of Testing
**Component specific
**Integration (regress, interaction can be without OpenArbor)
**OpenArbor integrated (configurations, user-like interactions)

==Automation Needed==
*Process a list of active components to build and test
*Detect commits made to the component since the last release
**Maintain a database of releases (component, distro, version number, svn version of build files)
**Scan server directories/files and update the database continuously
*Prepare a clean docker image for the build and test process and use for the remaining steps
*Checkout the component repository files (HEAD)
*Install all component dependencies for the component build
*Modify configure.ac (build version) and release notes
*Build the component
**If the build fails, send emails/notifications to the stakeholders and authors of commits since the last release (or at least author of most recent commit)
**If the build succeeds:
***Install any additional component dependencies for testing
***Log the versions of all components involved for test (examples, kernel, BSP, drivers, ...)
***Run the test suite
****If the tests fail, send emails/notifications to the stakeholders and authors of commits since the last release (or at least author of most recent commit)
****If the tests pass, check in the version updated files, and unrelease the component? Then send notification(s) to announce the new unrelease version?

=Continuous Deployment=
*Automatically unrelease updated components (for testing and release)
*Ideally, release updated components when automated build and testing pass without issues

=Possible Tools and Approaches=
*In-house scripts (python, bash, other)
*[https://www.jenkins.io Jenkins]
*[https://about.gitlab.com/solutions/continuous-integration/ GitLab CI/CD]

=Future Concerns=
* Ensuring that it is easily maintainable. Keeping in mind that maintainers are not expected/will not be asked to maintain any CI/CD things for their components. It is very important that whatever CI/CD turns into, it is easily maintainable. CI/CD should help decrease the workload of individual maintainers, not increase it.
** Avoiding tech debt, ensuring there is a solid architecture before getting into the implementation details.
* Need clear expectations and requirements from management on their goals (nightly builds, OA testing, regress, and further?).
** For the first release (June Tsunami), only nightly builds and an email system are expected. Only expecting to try building the components that are going into the DDS -- no need to test more than necessary.
** For future releases, we need to continue thinking about OA Testing Integration and Regress Suite Testing Integration.
*** Lots of technical details to flush out here eventually. Some ideas are: gitlab vs jenkins vs our own scripts, cdproc(-makefile?) integration, unrelease vs svn HEAD testing, being able to use real hardware (and what about replacing the boot images if we get unexpected failures? not standardized across the boards, some use tftpboot, some use USB sticks, etc...), programmatically determining the list of components to test, testing different variants (release, diagnostic, etc), knowing what architecture to test on, a through logging system, keeping track of testing history (database?). 

= Issues, Concerns, and Feedback =
<b>Add user feedback and issues here.</b><br>
* Build components on the build list only when a new change has been committed to the component
** Possible Solution
*** Check "svn info -r HEAD <component-path>" for "Last Changed" data (Rev, Date, and maybe Author), save data and compare against saved database/file to trigger build if new.
* Automated component build/test dependency identification and addition to build process.
* Build logs too long to include in emails (can crash Outlook)
** Possible Solution(s)
*** Attach log to email rather than including in message body
*** Provide link to build log file on the build host server


=Prototypes and Experiments=
==Python prototype==
Runs in a docker container. Processes a list of components, building a clean checkout of HEAD, and building HEAD with updated externals.<br>
[https://deos.ddci.com/svn/DDCI/contrib/cicd CI/CD scripts and support files]<br>
* Checkout directory and resulting text files are saved in the directory in which the script is run.
* If the build succeeds, the output text file ends with _cicd_results.log. A build error output file ends with _cicd_error.log.
* Builds checking with updated externals include _extern_up in the directory and output file names.
* Contacts (users/emails) extracted from svn log entries (last 5 for HEAD build, all in updated externals logs for updated externals build)
* smtp library in script, with function to send emails to contacts found if build fails. This has not been tested with an smtp server access set up yet.

Example outputs (test directory, build summaries):

{| class="wikitable"
|-
! scope=row | [[File:Cicd-proto-prelim-screenshot.png|thumb|Build directory view]]
| [[File:Build-report.png|thumb|Build Report Summary html]]
| [[File:Build-report-with-externals.png|thumb|Build Report Summary html<br>(with updated externals)]]
|}


<p> <br> </p>
[[Category:Projects]]
[[Category:Active_Projects]]
<!-- Uncomment one of these
[[Category:Completed_Projects]]
[[Category:On_Hold_Projects]]
[[Category:Active_Projects]]
-->
==Jenkins Builds==
The Jenkins Server is running on the remote machine: jenkins.ddci.com 
*Jenkins UI: http://jenkins.ddci.com:8080/
*Jenkins Built ChatBot from /desk/help of maintainer builds: http://jenkins.ddci.com:5000/DeosChatBot
Return to CI/CD.
Retrieved from "https://ddci.zapto.org/ddciWiki/CI/CD"
View source for CI/CD

Navigation menu

Page actions

Page actions

Personal tools

Navigation

Search

DDCI Tools & Resources

DDC-I private

Shared IP

Other

Tools
