All EdgeGallery Jenkins jobs have been managed by Jenkin Job Builder now instead of manually configured. That means all jobs you see in EdgeGallery Jenkins Portal can not been configured by manually click on the portal anymore. All your manually configurations are temporarily and will be reset after updating the jobs with the JJB Scripts which mantained by project ci-management. Here is the document about how to use the JJB to update the existing jobs or add some new jobs.
EdgeGallery use this CI/CD/CT Jenkins portal to do the following things:
Currently EdgeGallery CI/CD/CT has covered almost all projects and each project (or projects group) has a view for itself to list all jobs belonging to this project (or projects group). Take the website-gateway project as the example. The following figure shows the view of project website-gateway.
In order to make sure the CI team can get the right people as well as letting Jenkins to send the jobs failure email to him/her, following is a table to list all contact people for each project. Please feel free to add your name in.
|helm-chart||lizhiqian, Kanagemail@example.com, firstname.lastname@example.org|
|integration-testing||zhangali, email@example.com, firstname.lastname@example.org|
|mecm-applcm||Rama Subba Reddy S||Rama.Subba.Reddy.S@huawei.com|
|mecm-appo||Shashikanth V Hemail@example.com|
|installer||Kanag, B Sharath Kumar Reddyfirstname.lastname@example.org, email@example.com|
All developers should follow this guide for your daily development. These could make sure to get a relatively stable version everyday and help the developers to find out the issues in time. The following are some brief introduction about the existing jobs. All owner of each project should go to the project view to check the status of each jobs related to his/her projects. Please try your best to make sure all jobs are PASS and fix the known issue as soon as possible.
Every projects should define their own PR submit jobs to check the new codes submitted to review before merged. Each project are free to define what its PR submit job should do (e.g. do unit test, static code check...) and in which case it can say the new code submitted are fully test and can be merged. The results of this kind of job will be comment back to the PR page after several seconds (could be minutes if the pr check take a long time). Before you merge the PR, please make sure it get a PASS for the PR submit check job.
All Golang and JAVA projects are doing 3rdparty dependency check for every PR now. It's the same as PR submit job. You can get the detailed description about the 3rdparty dependency check with the following link:
The daily Docker image build jobs are building images (both x86 and arm64) for every projects daily and push them to SWR as well as create and push the manifest. The website-gateway docker build job is the first one to build because many other images are rely on this image. Also the pipeline will continue with the offline package, deploy and integration testing steps even though some images are failed to build. In this case, the existing images which may be built some days ago will be used.
The daily offline package build will be triggered after all docker images have been built and pushed. It will build the packages for all, controller and edge for both x86 and arm64. Then the packages will be pushed to the FTP server for user downloading.
The last step of the whole CI/CD/CT process is deploy and testing. There are 2 kings of deploy, one is daily deploy on Jenkins env and the other is deploy on test env for people who need to do the test manually or with the test case. Currently, it will deploy on Zijinshan Lab and Node45 test node.
After deployment, it will do the integration testing automatically and report the results of it.
The whole CI/CD/CT pipeline is triggered in the midnight everyday because there are two benefits of this time setting.
If you have any question or suggestion about this, please contact one of the following people