@jnyrup or @dennisdoomen
Can you please recheck the correct integration of coveralls with the github token (or a different one)?
I can't figure out why else this pipeline is failing at coveralls..

The token is correct and properly passed to the script. So something else is not right.

Hmm.. that odd.. I can't figure out what the problem is..

csMACnz/coveralls.net#108 indicates that we're passing the wrong kind of token.

--repoToken <repoToken> The coveralls.io repository token.

https://github.com/csMACnz/coveralls.net/blob/main/src/csmacnz.Coveralls/MainArgs.cs

Thank you for digging into this

I fear I cannot help with the token ;)

Just to make sure to not forget this check in NUKE build

I've just added a new Coveralls-specific token under the name COVERALLS_TOKEN. Try that one instead.

There must be an issue with permissions or something, because if I add a repo secret in my fork and use that instead.. it works

see this latest workflow run: https://github.com/IT-VBFK/fluentassertions/actions/runs/3919802757/jobs/6701153117
and the coveralls-page: https://coveralls.io/github/IT-VBFK/fluentassertions

New best guess about what's confusing us

With the exception of GITHUB_TOKEN, secrets are not passed to the runner when a workflow is triggered from a forked repository.

https://docs.github.com/en/actions/security-guides/encrypted-secrets#using-encrypted-secrets-in-a-workflow

uhh.. that's stupid.. that means we can't use that?

What a pity

uhh.. that's stupid..

It's for security.
https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions

Giving this a second thought, we didn't provide the Coveralls token before, so we shouldn't need it now.
Looking at the source for the currently used github actions task, it does use secrets.GITHUB_TOKEN.

Giving this a second thought, we didn't provide the Coveralls token before, so we shouldn't need it now.
Looking at the source for the currently used github actions task, it does use secrets.GITHUB_TOKEN.

But this didn't work either.. See the very first commits/workflow runs of this PR

What about using NUKE's secret parameter feature by storing the encrypted value in Build/parameters.json?

https://nuke.build/docs/fundamentals/parameters/#secret-parameters

Locally this works for me:

• Add [Secret] attribute to the coveralls variable in Build.cs and run ./build.sh once to generate the build.schema.json
• adding my coveralls token as a NUKE secret (in root dir run following):
  • nuke :secrets
  • choose the variable name
  • enter the secret
  • save & exit
• run ./build.sh again
• it should be working now (at least on my machine)

the only draw-back is, that you have to provide (or commit directly to this PR) the changed parameters.json, which holds the encrypted token

With the exception of GITHUB_TOKEN, secrets are not passed to the runner when a workflow is triggered from a forked repository.

This means that the secret is not available from a build that is part of the fork. And that makes total sense. We're running builds from the main repo. And we're also passing the Nuget push key in the exact same way. And that works.

Giving this a second thought, we didn't provide the Coveralls token before, so we shouldn't need it now.
Looking at the source for the currently used github actions task, it does use secrets.GITHUB_TOKEN.

That was my thought as well. I suspect that the GHA action for Coverall works in a different way than the .NET library

the only draw-back is, that you have to provide (or commit directly to this PR) the changed parameters.json, which holds the encrypted token

That is not an option.

That is not an option.

I have already guessed something like this :)

This means that the secret is not available from a build that is part of the fork. And that makes total sense. We're running builds from the main repo. And we're also passing the Nuget push key in the exact same way. And that works.

But this does not work either (see latest workflow runs). Both nuget api key and coveralls token are empty..

Have introduced the Info target again and check if NuGetApiKey and CoverallsToken are !string.IsNullOrWhitespace.

I think I will close this PR soon, because I think we're stuck here..

Sorry

Just to recap:

• Using GITHUB_TOKEN like in the coveralls action --> does not work
• Using a specific coveralls token works in the fork, but not in the main repo (when PR)
• Passing secrets.Token to NUKE --> does not work (Null or whitespace)
• Passing token via NUKE secret parameters --> declined
• Storing the token as repo variable (not as secret) --> definitely not an option

I just realized that since the variable name changed from ApiKey to NuGetApiKey no key is passed to NUKE anymore

Apparently, if merged into develop or master the key is passed.. but not in PRs.. but we want to get response about coverage especially in the PRs..

An other possibility could be to use an external key vault or AzureKeyVault (which is also supported by NUKE)

like proposed here: https://stackoverflow.com/a/67543604

An other possibility could be to use an external key vault or AzureKeyVault (which is also supported by NUKE)

like proposed here: https://stackoverflow.com/a/67543604

Not an option.
While we like to reduce the amount of yaml, introducing completely external systems introduces more complexity and fragility.

If we cannot find a way to inject some secret (github-token or coveralls token) into NUKE, then I say we keep it as it is right now.

Maybe this only works if me or @jnyrup trigger the build....

Maybe this only works if me or @jnyrup trigger the build....

Is this what we really want? Seems like a bad "hack"

As I don't have no ideas left.. I would close this..

Or do you have any ideas @jnyrup @dennisdoomen ?

I also out of ideas.

Ok.. seems we stick with yaml 🤔

Something is off. I've used repository secrets many times before. But looking at the flaky behavior we see with Coveralls right now, I'm starting to think we're facing the same problem there. When a contributor creates a PR, that PR won't get the right token and doesn't produce a Coveralls report. It always requires us to manually rebuild it.

But maybe I'm imagining things.

I will finish this if github ever introduces a fix for this problem