"fatal: bad object type" error when trying to upsert a (sliding) tag based on another extant tag

[cmpilato]

I have multiple github repositories which employ the same github workflows. One such is a reusable workflow that's part of a simple, manually triggered action. The action accepts as input a tag name and a deployment environment target (dev, prod, etc.). This workflow has a simple job: upsert a (sliding) tag into the repository called deployed-to-[environment], the sha of which matches that of the named "source" tag.

Here's the workflow YML in full:

name: Tag Deployment

on:
  workflow_call:
    inputs:
      target:
        description: "Deployment Target ('dev', 'prod', ...)"
        type: string
        required: true
      ref:
        description: "Git ref to tag"
        type: string
        required: true

jobs:

  update-deployment-tag:
    name: Upsert Deployment Tag
    runs-on: ubuntu-latest
    steps:

      # https://github.com/actions/checkout
      - uses: actions/checkout@v3
        with:
          ref: "${{ inputs.ref }}"

      # https://github.com/rickstaa/action-create-tag
      - uses: rickstaa/action-create-tag@v1
        with:
          tag: "deployed-to-${{ inputs.target }}"
          message: "Version currently deployed to '${{ inputs.target }}' environment"
          force_push_tag: true

This same workflow behaves as expected on several repositories, but on one in particular, it fails with fatal: bad object type. And I cannot discern the cause of this failure (and thus what must be unique about this one repository).

The checkout step seems to work fine, but then the tag creation just sorta unceremoniously falls over. And this happens whether the to-be-created tag already exists or not.

2023-07-13T18:46:00.1984193Z ##[group]Determining the checkout info
2023-07-13T18:46:00.1985152Z [command]/usr/bin/git branch --list --remote origin/0.0.2.101
2023-07-13T18:46:00.2024745Z [command]/usr/bin/git tag --list 0.0.2.101
2023-07-13T18:46:00.2060032Z 0.0.2.101
2023-07-13T18:46:00.2083515Z ##[endgroup]
2023-07-13T18:46:00.2084065Z ##[group]Checking out the ref
2023-07-13T18:46:00.2084667Z [command]/usr/bin/git checkout --progress --force refs/tags/0.0.2.101
2023-07-13T18:46:00.2426408Z Note: switching to 'refs/tags/0.0.2.101'.
2023-07-13T18:46:00.2447782Z 
2023-07-13T18:46:00.2448639Z You are in 'detached HEAD' state. You can look around, make experimental
2023-07-13T18:46:00.2450041Z changes and commit them, and you can discard any commits you make in this
2023-07-13T18:46:00.2450787Z state without impacting any branches by switching back to a branch.
2023-07-13T18:46:00.2451619Z 
2023-07-13T18:46:00.2452217Z If you want to create a new branch to retain commits you create, you may
2023-07-13T18:46:00.2453454Z do so (now or later) by using -c with the switch command. Example:
2023-07-13T18:46:00.2453863Z 
2023-07-13T18:46:00.2454729Z   git switch -c <new-branch-name>
2023-07-13T18:46:00.2455182Z 
2023-07-13T18:46:00.2456688Z Or undo this operation with:
2023-07-13T18:46:00.2457087Z 
2023-07-13T18:46:00.2457876Z   git switch -
2023-07-13T18:46:00.2458374Z 
2023-07-13T18:46:00.2459207Z Turn off this advice by setting config variable advice.detachedHead to false
2023-07-13T18:46:00.2459700Z 
2023-07-13T18:46:00.2460769Z HEAD is now at 56cf1f0 Some redacted thing
2023-07-13T18:46:00.2470208Z ##[endgroup]
2023-07-13T18:46:00.2486753Z [command]/usr/bin/git log -1 --format='%H'
2023-07-13T18:46:00.2517667Z '56cf1f0e31ff41f84a0357f3fa979ec165283d23'
2023-07-13T18:46:00.2882722Z ##[group]Run rickstaa/action-create-tag@v1
2023-07-13T18:46:00.2883090Z with:
2023-07-13T18:46:00.2883414Z   tag: deployed-to-prod
2023-07-13T18:46:00.2883786Z   message: Version currently deployed to 'prod' environment
2023-07-13T18:46:00.2884095Z   force_push_tag: true
2023-07-13T18:46:00.2884646Z   github_token: ***
2023-07-13T18:46:00.2885218Z   tag_exists_error: true
2023-07-13T18:46:00.2885521Z   no_verify_tag: false
2023-07-13T18:46:00.2885760Z ##[endgroup]
2023-07-13T18:46:00.3129732Z ##[command]/usr/bin/docker run --name c9a4a5fe520db488f4431590b5b84969aba6a8_424927 --label c9a4a5 --workdir /github/workspace --rm -e "INPUT_TAG" -e "INPUT_MESSAGE" -e "INPUT_FORCE_PUSH_TAG" -e "INPUT_GITHUB_TOKEN" -e "INPUT_COMMIT_SHA" -e "INPUT_TAG_EXISTS_ERROR" -e "INPUT_NO_VERIFY_TAG" -e "HOME" -e "GITHUB_JOB" -e "GITHUB_REF" -e "GITHUB_SHA" -e "GITHUB_REPOSITORY" -e "GITHUB_REPOSITORY_OWNER" -e "GITHUB_REPOSITORY_OWNER_ID" -e "GITHUB_RUN_ID" -e "GITHUB_RUN_NUMBER" -e "GITHUB_RETENTION_DAYS" -e "GITHUB_RUN_ATTEMPT" -e "GITHUB_REPOSITORY_ID" -e "GITHUB_ACTOR_ID" -e "GITHUB_ACTOR" -e "GITHUB_TRIGGERING_ACTOR" -e "GITHUB_WORKFLOW" -e "GITHUB_HEAD_REF" -e "GITHUB_BASE_REF" -e "GITHUB_EVENT_NAME" -e "GITHUB_SERVER_URL" -e "GITHUB_API_URL" -e "GITHUB_GRAPHQL_URL" -e "GITHUB_REF_NAME" -e "GITHUB_REF_PROTECTED" -e "GITHUB_REF_TYPE" -e "GITHUB_WORKFLOW_REF" -e "GITHUB_WORKFLOW_SHA" -e "GITHUB_WORKSPACE" -e "GITHUB_ACTION" -e "GITHUB_EVENT_PATH" -e "GITHUB_ACTION_REPOSITORY" -e "GITHUB_ACTION_REF" -e "GITHUB_PATH" -e "GITHUB_ENV" -e "GITHUB_STEP_SUMMARY" -e "GITHUB_STATE" -e "GITHUB_OUTPUT" -e "RUNNER_OS" -e "RUNNER_ARCH" -e "RUNNER_NAME" -e "RUNNER_ENVIRONMENT" -e "RUNNER_TOOL_CACHE" -e "RUNNER_TEMP" -e "RUNNER_WORKSPACE" -e "ACTIONS_RUNTIME_URL" -e "ACTIONS_RUNTIME_TOKEN" -e "ACTIONS_CACHE_URL" -e GITHUB_ACTIONS=true -e CI=true -v "/var/run/docker.sock":"/var/run/docker.sock" -v "/home/runner/work/_temp/_github_home":"/github/home" -v "/home/runner/work/_temp/_github_workflow":"/github/workflow" -v "/home/runner/work/_temp/_runner_file_commands":"/github/file_commands" -v "/home/runner/work/redacted/repository":"/github/workspace" c9a4a5:fe520db488f4431590b5b84969aba6a8
2023-07-13T18:46:00.6115484Z [action-create-tag] Create tag 'deployed-to-prod'.
2023-07-13T18:46:00.6124989Z fatal: bad object type.

And unlike the OP from issue #28, I don't know that removing the ref from my checkout action is an option here, nor does it seem to be required for several of my other repositories that do this exact same thing.

[0ui]

I also ran into the error message fatal: bad object type. in a reusable workflow. I unfortunately still don't know exactly what cause the issue but I was able to fix it by manually creating and pushing a new tag.

This may be a fundamentally different problem from yours but posting for anyone this might help:

1. my action was failing to create a tag pointing to HEAD and my latest tag was for HEAD~2
2. I manually created and pushed a tag for HEAD~1
3. the following action run was fixed and successfully created a tag for HEAD

[cmpilato]

I finally found something that seems to have worked. I changed the YAML stanza that I use to checkout the to-be-tagged repo to include the parameters fetch-depth: 0 and fetch-tags: true. The resulting block now looks like this:

      # https://github.com/actions/checkout
      - uses: actions/checkout@v3
        with:
          ref: "${{ inputs.ref }}"
          fetch-depth: 0
          fetch-tags: true

I'll close this issue now. (If @0ui or others want to reopen it, knock your-collective-selves out.)

[rickstaa]

Hey @cmpilato, great news on solving the issue! Apologies for the delay—I was enjoying a holiday in the sun. ☀️

The fatal: bad object error pops up when the Git ref is invalid, usually due to a typo or the ref not existing anymore.

In your code, focus on this section:

entrypoint.sh#L33C1-L33C48

It appears the problem might be after:

entrypoint.sh#L37C48-L37C48

git tag -fa "${TAG}" "${SHA}" -m "${MESSAGE}"

Given your use of force_push_tag, the error likely lies in the SHA variable. If commit_sha isn't specified, it's sourced from GITHUB_SHA:

GITHUB_SHA documentation

GITHUB_SHA value varies based on the triggering event. Usually, it's the latest commit, but in your case, it equals the Last commit on the branch or tag that received the dispatch:

GitHub Actions - Workflow Dispatch

I think this might lead to the ref not existing in your action. As you observed, running actions/checkout with fetch-depth: 0 fixes it by ensuring all Git refs are fetched during checkout.

I hope this sheds light! If you reencounter issues, let's revisit the investigation 👍🏻.

[rickstaa]

I improved the documentation (see #39).

[cmpilato]

I improved the documentation (see #39).

Excellent! Hopefully, others will benefit from my missteps and your additional documentation.

[rickstaa]

I improved the documentation (see #39).

Excellent! Hopefully, others will benefit from my missteps and your additional documentation.

Thank you for finding a use case which I did not think of and, by doing so, improving the action ❤️‍🔥.