common: add coverage scan

[janekmi]

This change is 

[codecov]

Codecov Report

Merging #5806 (f16d884) into master (1527cfc) will increase coverage by 0.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #5806      +/-   ##
==========================================
+ Coverage   70.97%   70.99%   +0.01%     
==========================================
  Files         131      131              
  Lines       19175    19175              
  Branches     3193     3192       -1     
==========================================
+ Hits        13610    13613       +3     
+ Misses       5565     5562       -3     

[grom72]

Reviewed 2 of 2 files at r1, all commit messages.
Reviewable status: all files reviewed, 3 unresolved discussions (waiting on @janekmi)

a discussion (no related file):
Shall we remove COVERAGE=1 from ubuntu.yml?

---

---

.github/workflows/scan_coverage.yml line 5 at r1 (raw file):

on:
  workflow_dispatch:

Let's make it simply sub-workflow

---

.github/workflows/scan_coverage.yml line 19 at r1 (raw file):

  OS_VER:       22.04
  COVERAGE:     1
  TEST_BUILD:   DEBUG

debug??

Code quote:

DEBUG

[janekmi]

Reviewed 1 of 2 files at r1, all commit messages.
Reviewable status: all files reviewed, 3 unresolved discussions (waiting on @grom72)

a discussion (no related file):

Previously, grom72 (Tomasz Gromadzki) wrote…

Shall we remove COVERAGE=1 from ubuntu.yml?

Actually, we agreed to keep it there since we still would like to see coverage change per pull request.

---

---

.github/workflows/scan_coverage.yml line 5 at r1 (raw file):

Previously, grom72 (Tomasz Gromadzki) wrote…

Let's make it simply sub-workflow

I recognize that sometimes we might need to run it manually to update the coverage after a more impactful change so pull requests coming later the same day would yield more accurate coverage results.

---

.github/workflows/scan_coverage.yml line 19 at r1 (raw file):

Previously, grom72 (Tomasz Gromadzki) wrote…

debug??

Good point. I think we can discuss it tomorrow. Till now coverage was always produced using debug builds.
But we know that these builds introduce additional logic e.g. more checks which may impact the final result.
I would say in a negative way. However, I would not expect a significantly different result when coverage would be measured using a nondebug build.

[janekmi]

Reviewed 1 of 2 files at r1.
Reviewable status: all files reviewed, 3 unresolved discussions (waiting on @grom72)

a discussion (no related file):
Preview: https://github.com/pmem/pmdk/actions/runs/5589044785/jobs/10216738281
Result: https://app.codecov.io/github/pmem/pmdk/commit/b6f63c6b52b1dac961d3debc80cdb30bc7c62119

---

[grom72]

Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @janekmi)

a discussion (no related file):

Previously, janekmi (Jan Michalski) wrote…

Actually, we agreed to keep it there since we still would like to see coverage change per pull request.

In that case, what is the added value of this scan?

---

---

.github/workflows/scan_coverage.yml line 19 at r1 (raw file):

Previously, janekmi (Jan Michalski) wrote…

Good point. I think we can discuss it tomorrow. Till now coverage was always produced using debug builds.
But we know that these builds introduce additional logic e.g. more checks which may impact the final result.
I would say in a negative way. However, I would not expect a significantly different result when coverage would be measured using a nondebug build.

I mean debug (lowercase) instead of DEBUG (uppercase).

[grom72]

Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @janekmi)

---

.github/workflows/scan_coverage.yml line 5 at r1 (raw file):

Previously, janekmi (Jan Michalski) wrote…

I recognize that sometimes we might need to run it manually to update the coverage after a more impactful change so pull requests coming later the same day would yield more accurate coverage results.

But in such case, we have a long All workflows list on Actions (https://github.com/pmem/pmdk/actions) page.

[osalyk]

Reviewed 2 of 2 files at r1, all commit messages.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @janekmi)

[janekmi]

Reviewable status: 1 of 2 files reviewed, 2 unresolved discussions (waiting on @grom72 and @osalyk)

a discussion (no related file):

Previously, grom72 (Tomasz Gromadzki) wrote…

In that case, what is the added value of this scan?

Oh, it turned out to be a really good question. I thought that since the main.yml is not triggered by push event the codecov.io report on the master branch is not being updated. But I am not 100% sure this is the case.

Let's discuss it offline.

---

---

.github/workflows/scan_coverage.yml line 5 at r1 (raw file):

Previously, grom72 (Tomasz Gromadzki) wrote…

But in such case, we have a long All workflows list on Actions (https://github.com/pmem/pmdk/actions) page.

Can we discuss functionality before aesthetics?

---

.github/workflows/scan_coverage.yml line 19 at r1 (raw file):

Previously, grom72 (Tomasz Gromadzki) wrote…

I mean debug (lowercase) instead of DEBUG (uppercase).

Done.

[grom72]

Reviewed 1 of 1 files at r2, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @janekmi)

[grom72]

Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @janekmi)

---

.github/workflows/scan_coverage.yml line 15 at r2 (raw file):

  PMDK_CC:      gcc
  PMDK_CXX:     g++
  VALGRIND:     0

We have to remember to use the same VALGRIND value for a similar workflow on pull_request.
Can we reuse this file there? I mean as an extension to #5807

Code quote:

VALGRIND:     0

[janekmi]

Reviewed 1 of 1 files at r2, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @osalyk)

---

.github/workflows/scan_coverage.yml line 15 at r2 (raw file):

Previously, grom72 (Tomasz Gromadzki) wrote…

We have to remember to use the same VALGRIND value for a similar workflow on pull_request.
Can we reuse this file there? I mean as an extension to #5807

We can consider using fromJSON() function providing the JSON e.g. from the repository variable.

Ref: https://docs.github.com/en/actions/learn-github-actions/expressions#fromjson
Ref: https://github.com/pmem/pmdk/settings/variables/actions/new

FYI @osalyk

[osalyk]

Reviewed all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @grom72)

[grom72]

Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @janekmi)

---

.github/workflows/scan_coverage.yml line 15 at r2 (raw file):

Previously, janekmi (Jan Michalski) wrote…

We can consider using fromJSON() function providing the JSON e.g. from the repository variable.

Ref: https://docs.github.com/en/actions/learn-github-actions/expressions#fromjson
Ref: https://github.com/pmem/pmdk/settings/variables/actions/new

FYI @osalyk

I mean add something like this to main.yml:

  call-coverage:
    uses: ./.github/workflows/scan_coverage.yml
    name: Coverage

[grom72]

Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @janekmi)

[janekmi]

Reviewed 1 of 1 files at r3, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @janekmi)

[janekmi]

Reviewed 2 of 2 files at r4, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @janekmi)

[grom72]

Reviewed 2 of 2 files at r4, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @janekmi)