You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This patch fixes the minor issues observed in Jenkinsfile
and update the CI doc.
Change-Id: I859844a2c17398675fa0a86c49a76793863975fb
Signed-off-by: rameshthoomu <rameshbabu.thoomu@gmail.com>
Copy file name to clipboardExpand all lines: README.md
+1Lines changed: 1 addition & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -153,6 +153,7 @@ Following are the steps to update cfssl package using version 1.0.8 of govendor
153
153
154
154
Please have a look at [Continuous Integration Process](docs/source/ca-ci.md)
155
155
156
+
156
157
## License <aname="license"></a>
157
158
158
159
Hyperledger Project source code files are made available under the Apache License, Version 2.0 (Apache-2.0), located in the [LICENSE](LICENSE) file. Hyperledger Project documentation files are made available under the Creative Commons Attribution 4.0 International License (CC-BY-4.0), available at http://creativecommons.org/licenses/by/4.0/.
This document explains the fabric-ca Jenkins pipeline flow and FAQ's on the build process to help developer to get more familiarize with the process flow.
3
+
This document explains the fabric-ca Jenkins pipeline flow and FAQ's on the build process
4
+
to help developer to get more familiarize with the process flow.
4
5
5
-
We use Jenkins as a CI tool and to manage jobs, we use [JJB](https://docs.openstack.org/infra/jenkins-job-builder). Please see the pipeline job configuration template here https://ci-docs.readthedocs.io/en/latest/source/pipeline_jobs.html#job-templates.
6
+
We use Jenkins as a CI tool and to manage jobs, we use [JJB](https://docs.openstack.org/infra/jenkins-job-builder).
7
+
Please see the pipeline job configuration template here https://ci-docs.readthedocs.io/en/latest/source/pipeline_jobs.html#job-templates.
6
8
7
9
## CI Pipeline flow
8
10
9
-
- Every Gerrit patchset triggers a verify job with the Gerrit Refspec on the parent commit of the patchset and run the below tests from the `Jenkinsfile`. Note: When you are ready to merge a patchset, it's always a best practice to rebase the patchset on the latest commit.
11
+
- Every Gerrit patchset triggers a verify job with the Gerrit Refspec on the parent commit
12
+
of the patchset and run the below tests from the `Jenkinsfile`. Note: When you are ready
13
+
to merge a patchset, it's always a best practice to rebase the patchset on the latest commit.
10
14
11
15
- Basic Checks (make checks)
12
16
- Documentation build (tox -edocs)
13
17
- Unit tests (make unit-tests)
14
18
- FVT tests (make fvt-tests)
15
19
- E2E tests (Only after patchset is merged)
16
20
17
-
All the above tests run on the Hyperledger infarstructure x86_64 build nodes. All these nodes uses the packer with pre-configured software packages. This helps us to run the tests in much faster than installing required packages everytime.
21
+
All the above tests run on the Hyperledger infarstructure x86_64 build nodes. All these nodes
22
+
uses the packer with pre-configured software packages. This helps us to run the tests in much
23
+
faster than installing required packages everytime.
18
24
19
-
Below steps shows what each stage does in the Jenkins pipeline verify and merge flow. Every Gerrit patchset triggers the fabric-ca-verify-x86_64 job and runs the below tests on x86_64 platform. Before execute the below tests, it clean the environment (Deletes the left over build artifiacts) and clone the repository with the Gerrit Refspec.
25
+
Below steps shows what each stage does in the Jenkins pipeline verify and merge flow.
26
+
Every Gerrit patchset triggers the fabric-ca-verify-x86_64 job and runs the below tests on
27
+
x86_64 platform. Before execute the below tests, it clean the environment (Deletes the left
28
+
over build artifiacts) and clone the repository with the Gerrit Refspec. Based on the file
29
+
extenstions, Jenkins pipeline script triggers the stages. If the patchset contains specific
30
+
doc extension, it only triggers **Docs Build** Stage otherwise it triggers all stages.
20
31
21
32
22
33
@@ -29,77 +40,106 @@ Below steps shows what each stage does in the Jenkins pipeline verify and merge
29
40
30
41
#### Docs Build
31
42
32
-
- This stage gets triggered only when a patchset contains .md, .rst etc doc related file exetensions.
33
43
- We run `tox -edocs` from the root directory.
34
-
- Displays the output in the form of HTML Publisher on the `fabric-ca-verify-x86_64` job. Click on **Docs Output** link on the Jenkins console.
44
+
- Displays the output in the form of HTML Publisher on the `fabric-ca-verify-x86_64` job.
45
+
Click on **Docs Output** link on the Jenkins console.
35
46
36
47
#### Unit Tests
37
48
38
-
- We run `make unit-test` target to run the go based unit-tests and publish the coverage report on the Jenkins console. Click on **Coverage Report** link on the Jenkins console.
49
+
- We run `make unit-test` target to run the go based unit-tests and publish the coverage
50
+
report on the Jenkins console. Click on **Coverage Report** link on the Jenkins console
51
+
to see the code coverage.
39
52
40
53
#### FVT Tests
41
54
42
-
- We run `make fvt-tests` target to fun fvt tests, which includes tests that perform end-to-end test scenarios with PosgreSQL and MySQL databases. These tests include database migration, backwards compatibility, and LDAP integration. https://github.com/hyperledger/fabric-ca/blob/master/scripts/fvt/README.md
55
+
- We run `make fvt-tests` target to run fvt tests, which includes tests that performs end-to-end
56
+
test scenarios with PosgreSQL and MySQL databases. These tests include database migration,
57
+
backwards compatibility, and LDAP integration. https://github.com/hyperledger/fabric-ca/blob/master/scripts/fvt/README.md
43
58
44
59
#### E2E tests
45
60
46
-
- We run **e2e tests** in the **merge job** and it performs the following tests. The intention of running e2e tests as part of the merge job is to test the dependent tests of fabric-ca.
47
-
- fabcar
48
-
- fabric-sdk-node - We run **gulp run-end-to-end** target which executes most of the end to end tests of fabric-sdk-node which are depend on fabric-ca.
49
-
- fabric-sdk-java - We run **ci_run.sh** script which is pre-baked in fabric-sdk-java repository.
61
+
- We run **e2e tests** in the **merge job** and it performs the following tests. The intention
62
+
of running e2e tests as part of the merge job is to test the dependent tests of fabric-ca.
63
+
- fabcar
64
+
- fabric-sdk-node - We run **gulp run-end-to-end** target which executes most of the end to end
65
+
tests of fabric-sdk-node which are depend on fabric-ca.
66
+
- fabric-sdk-java - We run **ci_run.sh** script which is pre-baked in fabric-sdk-java repository.
50
67
51
-
As we trigger `fabric-ca-verify-x86_64` and `fabric-ca-merge-x86_64` pipeline jobs for every gerrit patchset, we execute the tests in the below order.
68
+
As we trigger `fabric-ca-verify-x86_64` and `fabric-ca-merge-x86_64` pipeline jobs for every gerrit patchset,
69
+
we execute these tests in the below order.
52
70
53
-
After the DocsBuild is passed, Jenkins Pipeline triggers the Unit and FVT Tests parallel on two different nodes. After the tests are executed successfully it posts a Gerrit voting on the patchset. If DocsBuild fails, it send the result back to Gerrit patchset and it won't trigger further builds.
71
+
After the DocsBuild stage is passed, Jenkins Pipeline triggers the Unit and FVT Tests parallel
72
+
on two different nodes. After the tests are executed successfully it posts a Gerrit voting
73
+
on the patchset. If DocsBuild stage fails, it send the result back to Gerrit patchset and it
74
+
won't trigger further builds.
54
75
55
76
See below **FAQ's** for more information on the pipeline process.
56
77
57
78
## FAQ's
58
79
59
80
#### What happens on the merge job?
60
81
61
-
After the patchset got merged in the fabric-ca repository, it follows the above pipeline flow and executes the e2e tests in parallel to the Unit and FVT Tests.
82
+
After the patchset got merged in the fabric-ca repository, it follows the above pipeline flow and
83
+
executes the e2e tests in parallel to the Unit and FVT Tests.
#### What happens if one of the build stage fails?
79
102
80
-
As we are running these tests in `fastFailure: true` (if any build stage fails in the parallel process, it will terminate/abort the current running tests and sends the result back to the Gerrit Patchset. This way, CI will avoid runnning tests when there is a failure in one of the parallel build stage.
103
+
As we are running these tests in `fastFailure: true` (if any build stage fails in the parallel
104
+
process, it will terminate/abort the current running tests and sends the result back to the
105
+
Gerrit Patchset. This way, CI will avoid runnning tests when there is a failure in one of the
106
+
parallel build stage.
81
107
82
108
It shows `aborted` on the aborted stage on pipeline staged view.
83
109
84
110
#### How to re-trigger failed tests?
85
111
86
-
With this pipeline flow, you can not re-trigger specific failed job, instead you can post comments `reverify` or `reverify-x` on the gerrit patchset to trigger the `fabric-ca-verify-x86_64` job which triggers the pipeline flow as mentioned above. Also, we provided `remerge` or `remerge-x` comment phrases to re-trigger the failed merge jobs.
112
+
With this pipeline flow, you can NOT re-trigger the specific stage, but you can post comments
113
+
`reverify` or `reverify-x` on the gerrit patchset to trigger the `fabric-ca-verify-x86_64`
114
+
job which triggers the pipeline flow as mentioned above. Also, we provided `remerge` or `remerge-x`
115
+
comment phrases to re-trigger the failed merge jobs.
87
116
88
117
#### Where should I see the output of the stages?
89
118
90
-
Piepline supports two views (stages and blueocean). Staged views shows on the Jenkins job main page and it shows each stage in order and the status. For better view, we suggest you to access BlueOcean plugin. Click on the JOB Number and click on the **Open Blue Ocean** link that shows the build stages in pipeline view.
119
+
Piepline supports two views (staged and blueocean). **Staged views** shows on the Jenkins job main
120
+
page and it shows each stage in order and the status. For better view, we suggest you to access
121
+
BlueOcean plugin. Click on the JOB Number and click on the **Open Blue Ocean** link that shows
122
+
the build stages in pipeline view.
91
123
92
124
#### How to add more stages to this pipeline flow?
93
125
94
-
We use scripted pipeline syntax with groovy and shell scripts. Also, we use global shared library scripts which are placed in https://github.com/hyperledger/ci-management/tree/master/vars. Try to leverage these common functions in your code. All you have to do is, undestand the pipeline flow of the tests and conditions, add more stages as mentioned in the existing Jenkinsfile.
126
+
We use scripted pipeline syntax with groovy and shell scripts. Also, we use global shared library
127
+
scripts which are placed in https://github.com/hyperledger/ci-management/tree/master/vars.
128
+
Try to leverage these common functions in your code. All you have to do is, undestand the pipeline
129
+
flow of the tests and conditions, add more stages as mentioned in the existing Jenkinsfile.
95
130
96
131
#### How will I get build failure notifications?
97
132
98
-
On every merge failure, we send build failure email notications to the submitter of the patchset and send build details to the Rocket Chat **jenkins-robot** channel. Check the result here https://chat.hyperledger.org/channel/jenkins-robot
133
+
On every merge failure, we send build failure email notications to the submitter of the patchset
134
+
and send build details to the Rocket Chat **jenkins-robot** channel. Check the result here
#### What steps I have to modify when I create a new branch from master?
101
138
102
-
As the Jenkinsfile is completely parametrzed, you no need to modify anything in the Jenkinsfile but you may endup modifying **ci.properties** file with the appropirate Base Versions, Baseimage versions etc... in the new branch. We suggest you to modify this file immediately after you create a new branch to avoid running tests on old versions.
139
+
As the Jenkinsfile is completely parametrzed, you no need to modify anything in the Jenkinsfile
140
+
but you may endup modifying **ci.properties** file with the appropirate Base Versions,
141
+
Baseimage versions etc... in the new branch. We suggest you to modify this file immediately
142
+
after you create a new branch to avoid running tests on old versions.
103
143
104
144
#### What are the supported platforms
105
145
@@ -112,14 +152,18 @@ We use global shared library scripts and Jenkinsfile along with the build file.
112
152
113
153
Global Shared Library - https://github.com/hyperledger/ci-management/tree/master/vars
(Packer is a tool for automatically creating VM and container images, configuring them and post-processing them into standard output formats. We build Hyperledger's CI images via Packer and attach them to x86_64 build nodes. On s390x, we install manually. See the packages we install as a pre-requisite in the CI x86 build nodes.)
161
+
(Packer is a tool for automatically creating VM and container images, configuring them and
162
+
post-processing them into standard output formats. We build Hyperledger's CI images via Packer
163
+
and attach them to x86_64 build nodes. On s390x, we install manually. See the packages we
164
+
install as a pre-requisite in the CI x86 build nodes.)
122
165
123
166
#### How to reach out to CI team?
124
167
125
168
Post your questions or feedback in https://chat.hyperledger.org/channel/ci-pipeline or https://chat.hyperledger.org/channel/fabric-ci Rocket Chat channels.
169
+
You can also create a JIRA task or bug in FABCI project. https://jira.hyperledger.org/projects/FABCI
0 commit comments