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

Bugfix: CPPCHECK causes the Travis CI build to fail #668

Merged
merged 8 commits into from Jun 12, 2017

Conversation

Projects
None yet
4 participants
@gtrensch
Contributor

gtrensch commented Mar 2, 2017

This PR fixes a bug introduced with PR #546 commit bf46de3.

This change activates CPPCHECK again. All static code analysis messages will appear in the log and be collected by the parsing script. The result is "correctly" ignored now. Additionally, duplicate lines have been removed from build.sh.

gtr
- Activate CPPCHECK on Travis CI but ignore the result.
- Remove duplicate lines in build.sh.
@heplesser

@gtrensch I think we need to think more about how we handle activation/inactivation of tests, see my comments below.

Show outdated Hide outdated extras/parse_travis_log.py
Show outdated Hide outdated extras/parse_travis_log.py
@jougs

Thanks for fixing this. I've added some comments and suggestions.

Show outdated Hide outdated build.sh
Show outdated Hide outdated extras/parse_travis_log.py
Show outdated Hide outdated extras/parse_travis_log.py
@heplesser

This comment has been minimized.

Show comment
Hide comment
@heplesser

heplesser Mar 6, 2017

Contributor

@gtrensch Could you take a look at Travis build 1716.7? The build fails in that case, but the report then states

| Make                   | Skipped                                       |
|                        |                                               |
|                        | Errors  : None                                |
|                        | Warnings: None                                |
+------------------------+-----------------------------------------------+

Here, Make should report FAILED, and report that there was an error. Could you check the log-parser? I am also a bit surprised that the log reports S3-upload

+------------------------+-----------------------------------------------+
| Amazon S3 upload       | Yes                                           |
+------------------------+-----------------------------------------------+

but this may be correct.

Contributor

heplesser commented Mar 6, 2017

@gtrensch Could you take a look at Travis build 1716.7? The build fails in that case, but the report then states

| Make                   | Skipped                                       |
|                        |                                               |
|                        | Errors  : None                                |
|                        | Warnings: None                                |
+------------------------+-----------------------------------------------+

Here, Make should report FAILED, and report that there was an error. Could you check the log-parser? I am also a bit surprised that the log reports S3-upload

+------------------------+-----------------------------------------------+
| Amazon S3 upload       | Yes                                           |
+------------------------+-----------------------------------------------+

but this may be correct.

@gtrensch

This comment has been minimized.

Show comment
Hide comment
@gtrensch

gtrensch Mar 6, 2017

Contributor

You are right. There is a compile error in node_manager.cpp and the report should state failed. I will run the parsing script "offline" against that log.

Contributor

gtrensch commented Mar 6, 2017

You are right. There is a compile error in node_manager.cpp and the report should state failed. I will run the parsing script "offline" against that log.

@gtrensch

This comment has been minimized.

Show comment
Hide comment
@gtrensch

gtrensch Apr 5, 2017

Contributor

@heplesser the 'Make status' issue has been fixed with code change 098a686.
I also improved the reporting on the Amazon S3 deployment status (cb1f701). Since the upload is triggert by Travis after a successful build, it cannot be evaluated whether the upload was successful or not. Thus, the log parser script checks for the conditions only which lead to an upload. But I believe Travis itself reports on the deployment at the end of Travis run.

Contributor

gtrensch commented Apr 5, 2017

@heplesser the 'Make status' issue has been fixed with code change 098a686.
I also improved the reporting on the Amazon S3 deployment status (cb1f701). Since the upload is triggert by Travis after a successful build, it cannot be evaluated whether the upload was successful or not. Thus, the log parser script checks for the conditions only which lead to an upload. But I believe Travis itself reports on the deployment at the end of Travis run.

@heplesser

Just one little improvement left :).

if $IGNORE_MSG_CLANG_FORMAT; then
print_msg "MSGBLD1030: " "IGNORE_MSG_CLANG_FORMAT is set. CLANG_FORMAT messages will not cause the build to fail."
fi
if $RUNS_ON_TRAVIS && $IGNORE_MSG_PEP8; then

This comment has been minimized.

@heplesser

heplesser Apr 5, 2017

Contributor

The $RUNS_ON_TRAVIS is not needed here, it is take care of by the outer if.

@heplesser

heplesser Apr 5, 2017

Contributor

The $RUNS_ON_TRAVIS is not needed here, it is take care of by the outer if.

This comment has been minimized.

@gtrensch

gtrensch Apr 6, 2017

Contributor

@heplesser yes and no. I added the 'if $RUNS_ON_TRAVES' for 3 reasons.

  • clarity
  • robustness
    If the script runs locally, executed by 'check_code_style.sh', and someone changes its parametrization, for whatever reason, it will still behave reasonable. The ignore flags do not make sense outside Travis.
  • testing
    I used the 'check_code_style.sh' script for testing. Means, you can do the above without getting the second string, e.g. 'IGNORE_MSG_VERA is set. VERA++ .....'.
@gtrensch

gtrensch Apr 6, 2017

Contributor

@heplesser yes and no. I added the 'if $RUNS_ON_TRAVES' for 3 reasons.

  • clarity
  • robustness
    If the script runs locally, executed by 'check_code_style.sh', and someone changes its parametrization, for whatever reason, it will still behave reasonable. The ignore flags do not make sense outside Travis.
  • testing
    I used the 'check_code_style.sh' script for testing. Means, you can do the above without getting the second string, e.g. 'IGNORE_MSG_VERA is set. VERA++ .....'.
@gtrensch

This comment has been minimized.

Show comment
Hide comment
@gtrensch

gtrensch Apr 6, 2017

Contributor

@heplesser, @jougs
Important note !

Before merging this PR the "curly braces PR" #691 should be merged. This PR will turn on the VERA check again. CPPCHECK is also on. CPPCHECK messages will appear in the report but they are not taken into account for the build result. This PR does also not add the exclusion list.

Contributor

gtrensch commented Apr 6, 2017

@heplesser, @jougs
Important note !

Before merging this PR the "curly braces PR" #691 should be merged. This PR will turn on the VERA check again. CPPCHECK is also on. CPPCHECK messages will appear in the report but they are not taken into account for the build result. This PR does also not add the exclusion list.

@gtrensch

This comment has been minimized.

Show comment
Hide comment
@gtrensch

gtrensch Apr 6, 2017

Contributor

Set the IGNORE_MSG_VERA flag. See also PR #691.

Contributor

gtrensch commented Apr 6, 2017

Set the IGNORE_MSG_VERA flag. See also PR #691.

@heplesser

This comment has been minimized.

Show comment
Hide comment
@heplesser

heplesser Jun 12, 2017

Contributor

This looks fine now and since #691 has been merged, I will merge this as well.

Contributor

heplesser commented Jun 12, 2017

This looks fine now and since #691 has been merged, I will merge this as well.

@heplesser heplesser merged commit 079581a into nest:master Jun 12, 2017

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment