Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jenkins Integration #186

Merged
18 commits merged into from
Dec 3, 2018
Merged

Jenkins Integration #186

18 commits merged into from
Dec 3, 2018

Conversation

ghost
Copy link

@ghost ghost commented Nov 1, 2018

Description

Adding a Jenkinsfile and clang_patch script to support continuous integration testing on pull requests.
This Jenkinsfile will execute the following as a basic first step towards CI:

  • Run the linter (assuming clang-format for now, if that changes I will update this) and verify that no files modified by current pull request have linting issues. This doesn't check every file, only those modified from master (line 4 of .ci/clang_patch) so that lint errors won't be reported on files not touched. The clang_format.patch file is always archived by Jenkins for future reference, but when lint passes it should be a 0B file.
  • Run make ci for firmware/ec. This will build the firmware image with GCC and create an initial coverage report that shows 0 coverage for all source files. The unit tests are then run and coverage gathered for each one. The results are output as junit xml file that Jenkins can interpret, and .ci/coverage.py is run to convert lcov output to Cobertura format that Jenkins can interpret. After all these runs, the warnings output by the build are gathered by the console so that this can also be tracked by Jenkins, but will not cause a test failure.

Test Plan

Verify that the tests pass on this branch. Linter is not currently run unless PR #157 is closed and merged, then it should run and pass.
Unit tests should be reported as failed until #185 is closed and merged.
Verified clang patch by running it in top directory of the repo. Modified src/main.c by adding an extra empty line, just to verify that a modified file would be detected and patch file would be created.

Issues

#170

@ghost
Copy link

ghost commented Nov 12, 2018

Jenkins firmware test failed.
No test results found.

@ghost
Copy link

ghost commented Nov 12, 2018

Jenkins firmware test failed.
No test results found.

@ghost
Copy link
Author

ghost commented Nov 12, 2018

There will be a bunch of comments and updates on this PR as I mess with Jenkins stuff today, just giving a heads up.
Rerun tests.

@ghost
Copy link
Author

ghost commented Nov 12, 2018

rerun test

@ghost
Copy link
Author

ghost commented Nov 12, 2018

run tests

@ghost
Copy link
Author

ghost commented Nov 12, 2018

rerun tests

@ghost
Copy link
Author

ghost commented Nov 12, 2018

run test

@ghost ghost requested a review from dleang November 14, 2018 23:43
Copy link
Collaborator

@JoshuaJeyaraj JoshuaJeyaraj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have suggestion in addition to the lint we can do more ,
The current code base has a certain amount of warnings in linux build and CCS build . Can we use jenkins to ensure that the code which is getting added as part of PR doesn't add more warnings .

@@ -9,6 +9,7 @@
//*****************************************************************************
// HEADER FILES
//*****************************************************************************

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose that this extra line is to validate the script , please remove it before merging to master .

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that was just done because linter only runs on changed files in Jenkins, so I needed a .c file to be be detected as changed so that the linter would be run. I will change it back with next commit.

@@ -0,0 +1,37 @@
node {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we add some headers for all the new files

@JoshuaJeyaraj
Copy link
Collaborator

JoshuaJeyaraj commented Nov 16, 2018

Test Plan

Verified clang patch by running it in top directory of the repo. Modified src/main.c by adding an extra empty line, just to verify that a modified file would be detected and patch file would be created.

Can we do some more testing for valid/invalid entries?
As per the issue #170 description , does jenkins call these scripts only during creation of PR ? or does it do it for all proceeding commits ?

@ghost
Copy link
Author

ghost commented Nov 16, 2018

Can we do some more testing for valid/invalid entries?

I'm not sure what you mean by this, do you want the Jenkins tests to be added to or the Jenkinsfile to be tested more? Or more commits with errors to be made to verify the errors are caught?

As per the issue #170 description , does jenkins call these scripts only during creation of PR ? or does it do it for all proceeding commits ?

Jenkins is rerun every commit, and can be forced to re-run by commenting on the PR (Note my comments above.) Right now I have it set to only run my commits automatically so that all other PR's don't get reported as failing, but once this is merged I will add all of us to the list for automatic running.

I have suggestion in addition to the lint we can do more ,
The current code base has a certain amount of warnings in linux build and CCS build . Can we use jenkins to ensure that the code which is getting added as part of PR doesn't add more warnings .

Yes, right now in addition to lint it builds the firmware (currently only with GCC, looking to add a Windows node and CCS build in the future) and runs the unit tests. For the build, it collects and reports all the warnings (330 right now...), but as far as I can tell there is no way to automate that it fails if new warnings appear, we would have to manually check status ourselves...will look into that some more, but that would be changes on Jenkins server side I think, not in the Jenkinsfile itself.
It also tracks testing coverage, something else I would like to see if we can only improve or maintain with each commit, but that also is just tracked right now and not automatically shown.

@JoshuaJeyaraj
Copy link
Collaborator

I'm not sure what you mean by this, do you want the Jenkins tests to be added to or the Jenkinsfile to be tested more? Or more commits with errors to be made to verify the errors are caught?

more commits with errors to be made to verify the errors are caught assuming it is not yet done .

but once this is merged I will add all of us to the list for automatic running.

Great !!

For the build, it collects and reports all the warnings (330 right now...), but as far as I can tell there is no way to automate that it fails if new warnings appear, we would have to manually check status ourselves...will look into that some more, but that would be changes on Jenkins server side I think, not in the Jenkinsfile itself.

Can we count the number of warning from the build logs , if it goes above 330 we can treat it as new warnings in the PR ?

@ghost
Copy link
Author

ghost commented Nov 16, 2018

rerun tests

@ghost
Copy link
Author

ghost commented Nov 16, 2018

Rerun tests

@jspectacular
Copy link
Collaborator

Tests OK

@ghost
Copy link
Author

ghost commented Nov 28, 2018

more commits with errors to be made to verify the errors are caught assuming it is not yet done

I'll add a few failed commits today that should show the red x next to them indicating Jenkins test failures.

Can we count the number of warning from the build logs , if it goes above 330 we can treat it as new warnings in the PR ?

I suppose could hardcode the jenkinsfile to compare number of warnings to 330, but I don't really like that solution. Let's get the repo running CI first and I'll create an issue to make Jenkins fail on new build warnings for a future PR.

@ghost ghost requested a review from rkfillman December 3, 2018 17:41
Copy link
Collaborator

@rkfillman rkfillman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some of the discussion/comments here talk about upcoming work. Just want to make sure that its tracked somewhere so we don't forget about it.

@ghost
Copy link
Author

ghost commented Dec 3, 2018

Some of the discussion/comments here talk about upcoming work. Just want to make sure that its tracked somewhere so we don't forget about it.

Yup, added issue #210 last week to keep track of all the enhancements mentioned and other ones planned for future work.

@ghost ghost merged commit b05db18 into master Dec 3, 2018
@ghost ghost deleted the jenkins_file branch December 3, 2018 21:06
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants