Add token instructions to codecov-action

[fmauch]

Since 4v this is required. For this to work, adding a CODECOV_TOKEN action secret needs to be added to the GH repository.

This should fix our problems on uploading the code coverage as discussed in ros-controls/control_toolbox#188. Closes #15

In the target repo a secret has to be added in the project settings:
**

**

The token can be extracted on codecov.io.

[christophfroehlich]

I already had this, but it didn't work out well.
I tested the secrets: inherit option from the calling workflow from control_toolbox repository, but inside my fork I didn't have the token specified obviously. how does this work from our repos as well as from forks?

[christophfroehlich]

btw: you can test this with a calling workflow, where you specifiy your repo for the reusable workflow.

[fmauch]

I'll play around with that...

[christophfroehlich]

Maybe this is not required if we use secrets: inherit?

Note: If the secrets are inherited by using secrets: inherit in the calling workflow, you can reference them even if they are not explicitly defined in the on key.

https://docs.github.com/en/actions/using-workflows/reusing-workflows#using-inputs-and-secrets-in-a-reusable-workflow

[fmauch]

I am not sure whether this is then also unnecessary on the reusable workflow. I'm currently merely testing things, hence the draft state. I'm having the impression that things aren't sorted out with codecov's v4 action, though. With this version I'm having different trouble Commit creating failed: ["Service not found: none"] which seems to pop up in codecov/feedback#263. There seems to be a workaround, but I expect that runs us into codecov/codecov-action#1287. There seems to be work around this, e.g. codecov/codecov-action@f62c5ee.

We might consider going back to v3 until things are sorted out?

[christophfroehlich]

I suggested the same in the comment below ;)

[christophfroehlich]

it seems that v4 has lots of issues, and similar reported errors
codecov/codecov-action#1292
should we downgrade it to v4 until it get certainly fixed upstream?

[fmauch]

Without the custom path I got this working: https://app.codecov.io/gh/fmauch/control_toolbox/tree/test_coverage with corresponding https://github.com/fmauch/control_toolbox/actions/runs/8086437364/job/22096586430 and https://github.com/fmauch/control_toolbox/blob/test_coverage/.github/workflows/build-coverage.yml

[christophfroehlich]

Let's check if this works also from forks: fmauch/control_toolbox#1
I configured the other repos with secrets: inherit, I'm not sure where the advantages are..

[fmauch]

Let's check if this works also from forks: fmauch/control_toolbox#1 I configured the other repos with secrets: inherit, I'm not sure where the advantages are..

https://github.com/fmauch/control_toolbox/actions/runs/8095478742/attempts/1: "Secret CODECOV_TOKEN is required, but not provided while calling."

I can update this PR to not requiring it as an input and see whether inheriting works.

[fmauch]

Yep, that seems to be working: https://github.com/fmauch/control_toolbox/actions/runs/8095478742/job/22122490451

[christophfroehlich]

Great:

info - 2024-02-29 12:01:35,886 -- The PR is happening in a forked repo. Using tokenless upload.

You changed now my PR for ros-controls/control_toolbox. but let's merge this one first. We always can revert it ;)

[fmauch]

You changed now my PR for ros-controls/control_toolbox. but let's merge this one first. We always can revert it ;)

Ah sorry, I didn't realize you were using the same branch. for creating the PR at my fork.

Regarding the inherit vs. explicitly passing in the secret: When passing in the secret explicitly, the workflow could potentially be reused outside of the ros-controls organization. But for the moment I would also be fine with doing it that way.