Add cache for tblib compilation in release workflow

[Copilot]

• Add cache ID parameters to Dockerfile mount caches for proper identification
• Add reproducible-containers/buildkit-cache-dance action to release.yml for BuildKit cache persistence
• Configure scope-based GitHub Actions cache to persist caches across CI runs
• Update pull-request.yml to use the same caching approach
• Add explicit actions/cache@v4 step with platform-specific cache keys in release.yml
• Add cache-dir parameter to buildkit-cache-dance action
• Add skip-extraction based on cache hit status in release.yml
• Add explanatory comments in pull-request.yml about hardcoded linux/amd64 platform scope

Original prompt

增加一个release action编译tblib阶段的缓存加快编译速度

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[Copilot]

Pull request overview

This PR adds persistent caching for Docker BuildKit cache mounts to speed up compilation of the telegram-bot-api library (tblib) and Rust cargo builds in GitHub Actions. Previously, BuildKit cache mounts were not persisted across workflow runs. The change introduces the buildkit-cache-dance action to save and restore mount cache contents to GitHub Actions cache.

Key changes:

• Added cache mount IDs (tblib-build, cargo-cache) in Dockerfile for BuildKit cache identification
• Integrated reproducible-containers/buildkit-cache-dance@v3.2.0 in both release and pull-request workflows to persist cache mounts
• Updated BuildKit cache scopes to be platform-specific in release workflow (tblib-linux/amd64, tblib-linux/arm64)

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
Dockerfile	Added cache mount IDs to enable cache persistence for tblib build and cargo compilation stages
.github/workflows/release.yml	Integrated buildkit-cache-dance action to persist cache mounts with platform-specific BuildKit cache scopes
.github/workflows/pull-request.yml	Added buildkit-cache-dance with skip-extraction: true to read cache without writing, using hardcoded linux/amd64 scope

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The buildkit-cache-dance action may not automatically scope its GitHub Actions cache by platform. Since the release workflow can build for multiple platforms (linux/amd64 and linux/arm64 via workflow_dispatch), but the action configuration doesn't include platform information, there's a risk that:

1. Builds for different platforms will share the same cache key
2. The cache for one platform could overwrite the cache for another
3. This could lead to build failures or incorrect binaries when switching platforms

Verify whether the action supports a platform-specific cache key parameter (such as cache-key, cache-source, or similar). If supported, consider adding platform scoping:

with:
  cache-map: |
    {
      "tblib-build": "/src/build",
      "cargo-cache": "/src/target"
    }
  cache-key: ${{ steps.meta.outputs.platform }}

Alternatively, if the action doesn't support this, you may need to include the platform in the cache mount IDs themselves or verify that the action's default behavior already handles this correctly.

Suggested change

	}
	}
	cache-key: ${{ steps.meta.outputs.platform }}

[Copilot]

The cache scope is hardcoded to tblib-linux/amd64 but the pull-request workflow doesn't specify a platform for the build. This means:

1. If no platform is specified in the build action, it will default to the runner's platform (linux/amd64 on ubuntu-latest)
2. However, this is inconsistent with the release workflow which uses dynamic platform scopes based on steps.meta.outputs.platform

While this works for the current setup, it creates a maintenance burden. If someone later decides to test multi-platform builds in PRs or if the default runner platform changes, the hardcoded scope will cause cache misses or incorrect cache usage. Consider using a dynamic approach similar to the release workflow, or add a comment explaining why this is intentionally hardcoded to linux/amd64.

[hugefiver]

@copilot apply changes based on the comments in this thread

[Copilot]

@copilot apply changes based on the comments in this thread

Applied the review feedback in commit 6e858e7:

1. Added explicit actions/cache@v4 step with platform-specific cache keys (buildkit-cache-${{ steps.meta.outputs.platform }}-...) in release.yml
2. Added cache-dir: cache-mount parameter to buildkit-cache-dance action in both workflows
3. Added skip-extraction: ${{ steps.cache.outputs.cache-hit }} in release.yml to skip extraction when cache is already hit
4. Added explanatory comment in pull-request.yml about why the platform scope is hardcoded to linux/amd64

[Anthony-Hoo]

@codex 仔细review这个pr

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 6e858e7857

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Use the required cache-source input

Every release and PR build reaches this step, but v3.2.0's action metadata defines the required input as cache-source; cache-dir is not a supported input. Consequently GitHub Actions reports the unexpected input and cannot supply the restored cache-mount directory to the action, so the cache-dance step fails before the Docker build. Replace cache-dir with cache-source here and in pull-request.yml.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Invalidate the Cargo cache when dependencies change

When Cargo.lock changes without a Dockerfile edit, this key remains an exact hit; the later skip-extraction expression therefore evaluates to true, and the newly compiled /src/target contents are never saved. Because GitHub Actions caches are immutable, every subsequent release keeps restoring the pre-update target and recompiling the changed dependencies. Include hashFiles('Cargo.lock') in the primary key while retaining the existing restore prefix.

Useful? React with 👍 / 👎.