Skip to content

[UX] "Branch main is protected but no token was provided" is a lie #801

Description

@webknjaz

Describe the bug

This was mentioned in the action @ codecov/codecov-action#1918, and I've seen it before, I think.
Today, I saw it my CI, when I was wiring new repo, so I decided to take a closer look.

The uploader is pretty sure that the branch is not protected and claims so in this warning: https://github.com/tox-dev/tox-pre-commit/actions/runs/37032575031/job/110924028521#step:24:492. Then, it uses that as an excuse to explain why the token is needed saying that Token required because branch is protected in the error a few lines below.

The token might be expected, but the cause in the messages is untrue. The repository is new and doesn't have branch protection or rulesets configured. I think, this is what's been confusing people.

So it's sort of a UX problem. But also, it's a bit of an abstraction leak because people using GHA expect that the problem is in the action because they see the action printing out the error while the code is in the CLI which is kinda separate 🤷‍♂️

Expected behavior

I suppose the error message could be made cleaner to tell people to check if they'd enabled OIDC in the permissions key in the job definition if they use GitHub Actions CI/CD.

Regression

It's been like this since inception I recon 🤷‍♂️

Screenshots

https://github.com/tox-dev/tox-pre-commit/actions/runs/37032575031/job/110924028521#step:24:492

Product Area

coverage and test data uploaders

Versions

  • OS: N/A
  • Git Host: GitHub
  • CI/CD: GitHub Actions CI/CD
  • Uploader: codecov-action@v7

Commit and CI link

https://github.com/tox-dev/tox-pre-commit/actions/runs/37032575031/job/110924028521#step:24:492

Additional context

Here's where the warning is lying: https://github.com/codecov/codecov-cli/blame/c7e7bc0ce4fd57b0e349b3e09fcfed7e16f69637/codecov_cli/services/commit/__init__.py#L66

And the error lie is coming from the backend/API.

Activity

  1. jsoref commented on Oct 2, 2026

    @jsoref

    I mean, I don't have infinite time cycles. Certainly not to file a bug against the action, the cli, and the api. I think it's reasonable for an end user to say to a vendor "I used x, it gave me an error", and for the vendor to say "thanks, we as team A will file a bug on team B because we're using their thing and their thing gave us this error" and "team B can say thanks team A, we need to file a bug against team C because their thing gave us an unhelpful error". At the end of the day, it's likely that teams A, B, and C will have to coordinate, and that a fix to team A's code will be needed (either updating a dependency or updating error handling) -- even if only after team B does its work (turtles all the way down).

    That said, thanks for filing this bug 🙂.

  2. webknjaz commented on Oct 2, 2026

    @webknjaz
    ContributorAuthor

    Fair enough :) I guess, I just happen to have some more experience with how their apps are structured as I've contributed in the past to get things moving...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions