Scheduled run fails

[ben-manes]

I set up this action and the scheduled run failed with,

refs/heads/master not supported with 'schedule' event.
Only the default branch 'refs/heads/null' is supported

Since I followed your guide and did not modify this action, I think there is a missing step somewhere?

[godofredoc]

Here is an example from flutter failing because of the same reason.

[laurentsimon]

We fixed this in v1.0.3 https://github.com/ossf/scorecard-action/releases/tag/v1.0.3
If you've used the example workflow in the repo or the one from the GitHub UX tab, you're probably using an older version.

In the meanwhile, can you please use ossf/scorecard-action@b614d455ee90608b5e36e3299cd50d457eb37d5f , which is the hash for v1.0.3

Please confirm this works.

Let me update the documentation now.

[ben-manes]

In my case I did use v1.0.3 via a dependabot upgrade. Did the yaml file change between versions otherwise?

---

Bump ossf/scorecard-action from 1.0.2 to 1.0.3 (https://github.com/ben-manes/caffeine/pull/659)
Bumps [ossf/scorecard-action](https://github.com/ossf/scorecard-action) from 1.0.2 to 1.0.3.
- [Release notes](https://github.com/ossf/scorecard-action/releases)
- [Commits](https://github.com/ossf/scorecard-action/compare/c8416b0b2bf627c349ca92fc8e3de51a64b005cf...b614d455ee90608b5e36e3299cd50d457eb37d5f)

---
updated-dependencies:
- dependency-name: ossf/scorecard-action
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>

Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

ben-manes/caffeine@30f3a05

[laurentsimon]

correct. I was checking your hash and you have the right one. Flutter has the old one.
Could you run these lines https://github.com/ossf/scorecard-action/blob/main/entrypoint.sh#L51-L54 and tell me what you get?

[laurentsimon]

I think I've found the issue: your run logs hasRepository: null. I don't understand why the env variable GITHUB_REPOSITORY (https://docs.github.com/en/actions/learn-github-actions/environment-variables) is not set for schedule trigger, that's strange. Let me see what I can do.

[ben-manes]

I created a new token using the same permissions you have in the readme, then ran it:

curl -s -H "Authorization: Bearer $GITHUB_AUTH_TOKEN" https://api.github.com/repos/ben-manes/caffeine > repo_info.json
ben: caffeine $ echo $SCORECARD_PRIVATE_REPOSITORY
false
ben: caffeine $ echo $SCORECARD_DEFAULT_BRANCH
refs/heads/master

[laurentsimon]

We used to take this variable from the json payload https://github.com/ossf/scorecard-action/pull/83/files, but it turns out schedule events don't have one, so I switched to the env variable GITHUB_REPOSITORY.. which seems empty as well.
Bear with me. I need to find a way to get the original repository name...

[ben-manes]

no worries, thank you!

[laurentsimon]

cc @ChrisCarini

[ScottBrenner]

Found this issue via a similar failure in https://github.com/ScottBrenner/cfn-lint-action/runs/5074749835?check_suite_focus=true#step:4:15.

why the env variable GITHUB_REPOSITORY (https://docs.github.com/en/actions/learn-github-actions/environment-variables) is not set for schedule trigger

From https://github.community/t/repository-name-in-environment-variable/16856/7:

The schedule event does not have an event payload

Reference https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule

[laurentsimon]

Thank you. I expected the env variable to be set even though there's no event payload.. after all github.repository has nothing to do with the event payload, does it?

The ${{ github.repository }} is not directly accessible from an action, so I need to create an undocumented action argument to populate it. I'd like to avoid doing this, so I'll wait till I hear back from the GH support ticket I created. AFAICT, the GITHUB_REPOSITORY is not part of the payload event so it should be populated as per https://docs.github.com/en/actions/learn-github-actions/environment-variables

Thank you all for your help!

[laurentsimon]

cc @GuillaumeRoss who reported the same on the scorecard repo ossf/scorecard#1610

[mjpieters]

The repository info is available from the git checkout. Bash code I have running elsewhere (but should work on a GH runner after the actions/checkout step completed):

remote=$(git for-each-ref --format='%(upstream:remotename)' "$(git symbolic-ref -q HEAD)")
remote_url=$(git remote get-url "${remote}")

This retrieves the remote name for the current HEAD, then gets the URL for that remote. On any actions/checkout git clone that's exactly what you'd want; e.g. from my failed run logs you can see:

  /usr/bin/git remote add origin https://github.com/mjpieters/SO-userscripts

and the above bash code will set remote_url to https://github.com/mjpieters/SO-userscripts.

[mjpieters]

Other alternatives:

• If you are running js code somewhere in the action, add @actions/github as a dependency, then add import * as github from '@actions/github' and use github.context.repo.owner plus github.context.repo.repo, just like the @actions/checkout code does, an combine that with GITHUB_SERVER_URL, GITHUB_URL or just https://github.com, again same as the checkout action.

• If you are not running js code, then the @actions/github module gets the repository info from the Webhook payload, so find GITHUB_EVENT_PATH, load the JSON from that path and you'll have the same data you now get from the https://api.github.com/repos/$GITHUB_REPOSITORY api call under the repository object.

However, since scheduled runs don't have a webhook payload, these paths probably will be dead ends too. I suspect that the @actions/checkout action repository input is set explicitly for these runs so it never has to fall back to the github.context.repo.* values. In which case getting the remote from the checkout is still a very viable alternative as that recorded the very same info.

[mjpieters]

Ah, found it; the @actions/checout action schema uses the github.repository workflow variable as a default.

So, that provides you with another alternative: add a repository input to the ossf/scorecard-action action schema and use github.repository as a default. :-D

[laurentsimon]

github.repository is the backup plan, yes: add an argument and default to github.repository. Thanks for confirming. I'd like to avoid creating an additional argument if GITHUB_REPOSITORY can be populated by GH automatically - see #84 (comment)

They are investing atm. The variable should be set, should it not?

[laurentsimon]

Finally found some time to dig into this. GITHUB_REPOSITORY is not null. I think if you use our repo at head, the schedule works. I've sent an additional #98 to fix wrong "Is fork" debugging message.

We'll cut a new release as per #97

[mjpieters]

I think if you use our repo at head, the schedule works.

The schedule does run on repo head, and failed. This failed, scheduled run was executed against the main branch of the repository. The @action/checkout configuration, with all the action defaults provided by GH:

  with:
    persist-credentials: false
    repository: mjpieters/SO-userscripts
    token: ***
    ssh-strict: true
    clean: true
    fetch-depth: 1
    lfs: false
    submodules: false

checked out revision c3faf844845191f9a19cf68f1082fb4632e45a9b, which was the head at the time of the run:

   * [new ref]         c3faf844845191f9a19cf68f1082fb4632e45a9b -> origin/main

The ossf/@scorecard-action output agrees it is refs/heads/main they are working with, but then bails because:

Only the default branch 'refs/heads/null' is supported

null means the curl -s -H "Authorization: Bearer $GITHUB_AUTH_TOKEN" https://api.github.com/repos/$GITHUB_REPOSITORY > repo_info.json fetch failed.

[mjpieters]

Side note: I strongly recommend you run curl commands with --fail or --fail-with-body (the latter is a fairly recent option, curl 7.76.0 or newer required) and checking the exit code. Or, use -o repo_info.json -w '%{http_code}', which sends the status code to stdout and the body directly to the output file:

status_code=$(curl -s -H "Authorization: Bearer $GITHUB_AUTH_TOKEN" https://api.github.com/repos/$GITHUB_REPOSITORY -o repo_info.json -w '%{http_code}')
if [[ $status_code -ge 400 ]]; then
    error_msg=$(jq -r .message repo_info.json 2>/dev/null || echo 'unknown error')
    echo "Failed to get repository information from GitHub, response $status_code: $error_msg"
    exit 1;
fi

Since the runners are using Ubuntu Focal (20.04LTS) I think their curl version isn't new enough yet to use --fail-with-body (version 7.68.0).

[ben-manes]

I think if you use our repo at head, the schedule works.

The schedule does run on repo head, and failed. This failed, scheduled run was executed against the main branch of the repository.

@laurentsimon meant that he thinks this issue was fixed in an unreleased version (probably 6cc0399), so changing the action's hash from ossf/scorecard-action@b614d45 to ossf/scorecard-action@869bc60 in your workflow file might resolve the issue.

[mjpieters]

@laurentsimon meant that he thinks this issue was fixed in an unreleased version (probably 6cc0399), so changing the action's hash from ossf/scorecard-action@b614d45 to ossf/scorecard-action@869bc60 in your workflow file might resolve the issue.

Ah! Check! That's the part I missed then.

[laurentsimon]

Thanks @ben-manes for the clarification, that's indeed what I meant.
@mjpieters thanks for the suggestion about curl's best practice.