"Couldn't find a repository matching this job" in GitHub Actions since v1.3.5

[ruippeixotog]

I've been trying for a while to upgrade sbt-coveralls from v1.3.2 to a newer version on my projects, but even after you fixed multiple issues affecting me (such as #224 and #250), I'm still unable to upload coverage data from GitHub Actions.

Taking https://github.com/ruippeixotog/akka-testkit-specs2 as an example, using v1.3.2 works well (see "Upload coverage data to Coveralls" step). v1.3.3 and v.1.3.4 suffer from unrelated issues so I can't test them, but I could confirm that v1.3.5 doesn't work. The latest version v1.3.8 behaves the same way.

I tried with both pull requests and push CI triggers, so this doesn't seem to be due to the behavior of actions/checkout explained in the README. I tried searching through the commits, but 547ad2a changed too many things. Do you have any idea what might be happening?

[rolandtritsch]

Hi Rui.

Can you try to fork, clone, build this repo and see, if that works?

I just tried this and it works for me.

And then please replace the token in ./.coverallsToken with your own token.

[ruippeixotog]

@rolandtritsch I an do that, but I be testing the right thing? My problem happens on GitHub Actions, where I'm not specifying the token manually - I pass the default CI token like this. I imagine that by doing what you're suggesting I won't have any problems as I'm passing a token explicitly.

[rolandtritsch]

Hi Rui,

You are assinging the GITHUB_TOKEN as the COVERALLS_REPO_TOKEN. These are two different tokens.

Please read this - https://docs.github.com/en/actions/security-guides/encrypted-secrets.

You need to create a secret (e.g. COVERALLS_REPO_TOKEN) and assign it like this ...

          COVERALLS_REPO_TOKEN: ${{ secrets.COVERALLS_REPO_TOKEN }}

This is not an issue with sbt-coveralls. I am going to close this issue.

[ruippeixotog]

Hi @rolandtritsch, I don't think that's true - manually setting a COVERALLS_REPO_TOKEN wasn't needed before. Coveralls has special support for many CI services, usually in the form of accepting CI-specific tokens. I was the one that added support for GitHub Actions to this plugin (#128) and I used the same method as the official Coveralls GitHub Action, which doesn't require COVERALLS_REPO_TOKEN either.

If anything, the fact that this works perfectly on v1.3.2 but not on later versions makes this a regression and it would be worth understanding why so we can re-add support.

[ruippeixotog]

@rolandtritsch, could you please take a look at the comment above and reopen this issue if you agree with it?

[rolandtritsch]

Hi Rui. I am on vacation. Will take a look next week. - RT

…

On Thu, May 25, 2023 at 7:25 AM Rui Gonçalves ***@***.***> wrote: @rolandtritsch <https://github.com/rolandtritsch>, could you please take a look at the comment above and reopen this issue if you agree with it? — Reply to this email directly, view it on GitHub <#257 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFD5FPLLGM2PQ462NNKWZLXH33OLANCNFSM6AAAAAAXKGIWEE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[rolandtritsch]

Hi Rui,

I just configured a workflow for this repo from scratch.

To make it work I obviously had to configure a/the secret.

Afterwards the report was uploaded successfully.

Feel free to fork the repo, configure the secret on the forked repo and try that it works for yourself.

[ruippeixotog]

Hi @rolandtritsch, I'm afraid there's still a misunderstanding here. I know that the plugin works if you follow the current instructions and pass a Coveralls repo token - I just disagree that I need to pass the token explicitly.

Despite you saying that it's "obvious" you have to do it, the fact is that I have repos using sbt-coveralls v1.3.2 with NO explicit Coveralls token. And I must say it's a bit strange that you're not even putting it into question given I said I was the one that originally implemented GitHub Actions support in this plugin (#128) - I suppose I still know what I needed at the time and what I didn't need?

It's perfectly ok if you're saying that you only want to support users passing the Coveralls token explicitly, or that you don't have the time or interest to work on fixing this - it's just objectively wrong to say that 1) this wasn't a regression or 2) that it isn't possible 🙂

[ruippeixotog]

I did a few tests and got the root cause - #212 broke existing behavior by switching name in GitHubActions to be an empty string.

A repo token in Coveralls does not need to be the token provided by them. That token can be used as a universal solution for non-supported CI services, but Coveralls uses the "repo_token" field in coveralls.json to decide what kind of token it is. In early days, it started by supporting Travis API tokens when the service name was "travis-ci" / "travis-pro". They added support for GitHub later, where they interpret the token as a GitHub token (see how they do that in their official GitHub Action).

@viktor-podzigun's issue in #211 was likely that he was manually setting COVERALLS_REPO_TOKEN in GitHub CI, which wasn't supported because Coveralls was expecting a GitHub token. Unfortunately, Viktor's fix broke the old behavior (before this PR, this simply worked).

I'll try to put up a pull request with a solution that works for both cases.

[viktor-podzigun]

@ruippeixotog I think your thinking is correct, setting name to empty string removes the support for github service. I was not sure about that change since setting COVERALLS_REPO_TOKEN was working. Reading your explanation it all makes sense now.

So, I would suggest that we may support both cases actually:

• if COVERALLS_REPO_TOKEN env var is present then it is currently supported case and we should keep name empty
• else we should set name back to github and pass through GitHub token

[rolandtritsch]

Hi @ruippeixotog. Sorry for the missunderstanding. And yes, a PR would be appreciated. And I agree with @viktor-podzigun: If we can, we should support both cases. WDYT?

[ruippeixotog]

Yep, I agree with the approach 👍 I'll work on a PR later this week, though first I need to solve a different issue also introduced in v1.3.5 (e.g. this CI job, some issue related with handling of version-specific folders like these).