gpg: signing failed: No secret key

I've followed the steps using crazy-max/ghaction-import-gpg as the documentation recommended.

However I'm having no luck getting the commitizen-action to sign the commits/tags etc.

name: Bump Version

on:
  push:
    branches:
      - main

jobs:
  build:
    if: "!startsWith(github.event.head_commit.message, 'bump:')"
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
        with:
          fetch-depth: 0
          token: ${{ secrets.PERSONAL_ACCESS_TOKEN }}
      - name: Import GPG key
        id: import_gpg
        uses: crazy-max/ghaction-import-gpg@v5
        with:
          gpg_private_key: ${{ secrets.GPG_PRIVATE_KEY }}
          passphrase: ${{ secrets.GPG_PASSPHRASE }}
          trust_level: 5
          git_user_signingkey: true
          git_commit_gpgsign: true
          git_tag_gpgsign: true
          git_config_global: true
      - name: List keys
        run: |
          gpg --list-keys
          echo ${{ steps.import_gpg.outputs.fingerprint }}
          echo ${{ steps.import_gpg.outputs.keyid }}
          git config --global --list
      - name: Create bump and changelog
        uses: commitizen-tools/commitizen-action@master
        with:
          github_token: ${{ secrets.PERSONAL_ACCESS_TOKEN }}
          git_name: ${{ steps.import_gpg.outputs.name }}
          git_email: ${{ steps.import_gpg.outputs.email }}
          changelog_increment_filename: VERSION.md
          gpg_sign: false
          debug: true
      - name: Output REVISION
        run: |
          echo ${{ env.REVISION }}
      - name: Release
        uses: softprops/action-gh-release@v1
        with:
          body_path: "VERSION.md"
          tag_name: "v${{ env.REVISION }}"
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Commitizen version: 3.5.2
cz --debug --no-raise 21 bump --yes --gpg-sign --changelog --check-consistency
bump: version 0.0.2 → 0.0.3
tag to create: v0.0.3
increment detected: PATCH

[main 6aee056] bump: version 0.0.2 → 0.0.3
 1 file changed, 13 insertions(+)

error: gpg failed to sign the data:
gpg: directory '/github/home/.gnupg' created
gpg: skipped "brazarb <11[102](https://github.com/org/ClickUpTest/actions/runs/*******/jobs/*********#step:6:103)******+******@users.noreply.github.com>": No secret key
[GNUPG:] INV_SGNR 9 author <*******+******@users.noreply.github.com>
[GNUPG:] FAILURE sign 17
gpg: signing failed: No secret key

error: unable to sign the tag

Traceback (most recent call last):
  File "/usr/local/bin/cz", line 8, in <module>
    sys.exit(main())
  File "/usr/local/lib/python3.8/site-packages/commitizen/cli.py", line 463, in main
    args.func(conf, vars(args))()
  File "/usr/local/lib/python3.8/site-packages/commitizen/commands/bump.py", line 351, in __call__
    raise BumpTagFailedError(c.err)
commitizen.exceptions.BumpTagFailedError: error: gpg failed to sign the data:
gpg: directory '/github/home/.gnupg' created
gpg: skipped "author <******+******@users.noreply.github.com>": No secret key
[GNUPG:] INV_SGNR 9 author <******+******@users.noreply.github.com>
[GNUPG:] FAILURE sign 17
gpg: signing failed: No secret key

error: unable to sign the tag

Checking git config --global --list matches the name, email and signing key.

Is this the reason #50 (comment)?

If so, any plans on how to solve this?

@brazarb

@brazarb we're you able to sign off commits, i am using a similar approach to yours and keep getting the same error

@brazarb

@brazarb you can give this a look, it was of help
https://github.com/adam-grant-hendry/poetry_plugin_constrain/blob/main/.github/workflows/release.yml

@adam-grant-hendry

Also running into this issue. It appears to be because the commitizen action is run in a Docker image using a different version of gpg and in-container configuration path, whereas crazy-max/ghaction-import-gpg is not containerized and configures gpg in the context of a given runner job. Unless commitizen-tools/commitizen-action is able to mount those user/gpg config directories, gpg signing will never work inside this action.

CC: @adam-grant-hendry

possible workaround

Have a look into the log files and investigate the docker command line. In my case it were /usr/bin/docker run --name … --label … --workdir … --rm … … … -v "/home/runner/work/_temp/_github_home":"/github/home". The bolded volume argument is crucial and direct to the following step you should execute after crazy-max/ghaction-import-gpg and before commitizen-tools/commitizen-action:

- name: Export GPG keys to Docker container
  run: |
    # docker run … … … -v "/home/runner/work/_temp/_github_home":"/github/home"
    mkdir -p "${HOME}/work/_temp/_github_home/"

    cp -av "${HOME}/.gnupg/" "${HOME}/work/_temp/_github_home/.gnupg/"
    gpg --homedir "${HOME}/work/_temp/_github_home/.gnupg/" --list-secret-keys
    sudo chown -R root:root "${HOME}/work/_temp/_github_home/.gnupg/"

Sadly, later inside the running Docker container, you will get an GPG error (gpg: error running '/usr/bin/gpg-agent': probably not installed). The current Dockerfile needs to patch:

diff --git a/Dockerfile b/Dockerfile
index f9daacf..695f34d 100644
--- a/Dockerfile
+++ b/Dockerfile
@@ -5,6 +5,7 @@ RUN set -eux; \
         git \
         git-lfs \
         gpg \
+        gpg-agent \
         alpine-sdk \
         bash \
         libffi-dev \

I'm adding gpg-agent in #104

Have you tried configuring the gpg action to change the workdir?

id: import_gpg
uses: crazy-max/ghaction-import-gpg@v5
with:
  workdir: ${{ env.GITHUB_WORKSPACE }}
  # ...

I'm not sure if that's the correct variable, but github exposes a lot, maybe with this change + using workdir it works

I'm adding gpg-agent in #104

👍🏼 many thx, hopefully it can merge in ASAP.

Have you tried configuring the gpg action to change the workdir?

id: import_gpg
uses: crazy-max/ghaction-import-gpg@v5
with:
workdir: ${{ env.GITHUB_WORKSPACE }}

...

I'm not sure if that's the correct variable, but github exposes a lot, maybe with this change + using workdir it works

I think, that can't help here. The two steps with their actions have different workspace folders, because of there different (HOME) base folders. The crazy-max/ghaction-import-gpg runs directly on GH runner host (HOME is in my case /home/runner/) and commitizen-tools/commitizen-action runs inside the Docker container (HOME is in my case /github/home/ – binded by docker run to the GH runner host folder /home/runner/work/_temp/_github_home). Thus the HOME folder are completely different and $HOME/.gnugp will never expand to the same GH runner host folder.

As I can see in crazy-max/ghaction-import-gpg#55 the workdir parameter is only usefull for raw git operations – not for the gpg command. Even if this (coincidentally) also affected the storage location of the .gnugp folder (I don't know the code of crazy-max/ghaction-import-gpg in detail), the problem of the incorrect ownership of the .gnugp folder would remain. The Docker container will run with root, but the folder would exist with host-level permissions as GH runner user – so the sudo hack would still be necessary. It's not that simple.

Maybe a little bit more "copy magic" in the entrypoint.sh can help to avoid that ugly interime step –> https://github.com/orgs/community/discussions/25637#discussioncomment-3248560

Triage: partially addressed — #104 (merged) added gpg-agent to the Docker image, which fixes the probably not installed error.

The remaining issue is that crazy-max/ghaction-import-gpg writes ~/.gnupg on the runner host (e.g. /home/runner/.gnupg), but the commitizen-action container only mounts /home/runner/work/_temp/_github_home as the container's /github/home. So the keys are unreachable from inside the container even with gpg-agent present.

The workaround @rexut posted is the right shape — copy the .gnupg directory into \C:\Users\bear8/work/_temp/_github_home/ before invoking the action, with root ownership. Worth folding that into the README's GPG-signing section as the recommended setup.

Beyond docs, a more robust fix would need either (a) the gpg-import action exposing a workdir that affects the gnupg homedir, or (b) this action arranging the volume mounts itself, which Docker container actions don't really allow. So the doc-update path is probably the best we can do here.

Navigation Menu

Repository navigation

gpg: signing failed: No secret key #72

possible workaround

...

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

gpg: signing failed: No secret key #72

Description

Activity

brazarb commented on Jun 28, 2023

victorkambi commented on Jul 17, 2024

victorkambi commented on Jul 23, 2024

amilstead commented on Apr 7, 2025

rexut commented on Nov 19, 2025

possible workaround

woile commented on Nov 19, 2025

rexut commented on Nov 19, 2025

...

bearomorphism commented on May 10, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions