giis-uniovi / modevo

Model-driven approach to maintain data integrity for evolution of column family DBMSs
Apache License 2.0
1 stars 2 forks source link

Post Migration - Split UT and IT in separate jobs #21

Closed javiertuya closed 2 months ago

javiertuya commented 2 months ago

Review things that were left pending in #7:

You can see an example in other repositories, eg. tdrules. Note that the tdrules reporting is a little bit more complicated (but this is not needed here) as we do not need a separate job for test reports becasue we are not going to publish en GH actions.

giis-qabot commented 2 months ago

@suarezgpablo This is a reminder about this issue because it has not been updated for 10 days

javiertuya commented 2 months ago

I've checked the Sonar main branch and it seems that it is only getting coverage from one of the modules:

https://sonarcloud.io/component_measures?metric=coverage&id=my%3Amodevo

suarezgpablo commented 2 months ago

I've checked the Sonar main branch and it seems that it is only getting coverage from one of the modules:

https://sonarcloud.io/component_measures?metric=coverage&id=my%3Amodevo

@javiertuya I was able to fix another mistake that I had where test-report-ALL was empty but I'm stuck on this issue.

I tested it with several options but I always ended up with the coverage of only one module, the last one of the restore-artifact-name# list. For instance, right now it is only getting coverage from the script module, which is given to sonarqube through "restore-artifact-name2". If I remove "restore-artifact-name2" then it analyzes the transform module, which is give to sonarqube through "restore-artifact-name1". In summary, it ignores all but the last of test-report-files.

I checked with giis-uniovi/tdrules and I think that I'm doing the same as there. I also checked the documentation of javiertuya/sonarqube-action and I think that I'm not missing any required parameters. Could you take a quick look to see if I'm maybe overlooking something?

  ```- uses: javiertuya/sonarqube-action@v1.3.1
    with: 
      github-token: ${{ secrets.GITHUB_TOKEN }}
      sonar-token: ${{ secrets.SONAR_TOKEN }}
      restore-artifact-name1: "test-report-files-transform"
      restore-artifact-name2: "test-report-files-script"```
javiertuya commented 2 months ago

@suarezgpablo From what you are saying I can guess that you are overwriting the files, i.e. when sonarqube-action restores the artifacts, the restore of artifact 2 overwrites the jacoco file that was restored from artifact 1, therefore, you only see the coverage from artifact 2, that is the coverage of the second module.

Look at the generated artifacts to check if the coverage files have the same name and path. I you can see, restore the artifacts from the job and use ls to check the restored files.

Another issue is that you are still running maven with aggregate=true, what is not needed if each report only the results of each module (although this is applicable to the test results).

suarezgpablo commented 2 months ago

@suarezgpablo From what you are saying I can guess that you are overwriting the files, i.e. when sonarqube-action restores the artifacts, the restore of artifact 2 overwrites the jacoco file that was restored from artifact 1, therefore, you only see the coverage from artifact 2, that is the coverage of the second module.

Look at the generated artifacts to check if the coverage files have the same name and path. I you can see, restore the artifacts from the job and use ls to check the restored files.

Another issue is that you are still running maven with aggregate=true, what is not needed if each report only the results of each module (although this is applicable to the test results).

Yes, you were right, it was overwriting the coverage files of the transform-module. The problem was related to the one that I mentiones in the first pull request about executing the tests of the transform module in the script module. The problem was that even if no tests were executed, it still creates a folder for the coverage files, overwriting the folder that contains the actual results when restoring it. I solved it by restoring the files of the transform module after restoring the files of the script module.