Trigger documentation site rebuild after function release

[aravindtga]

Description

• What changed: Added a step to the after-tag-with-version.yaml workflow that triggers a Netlify documentation site rebuild after every function release tag push.
• Why it's needed: The homepage function catalog table fetches release versions from the GitHub API via Hugo's resources.GetRemote at build time. Since releases are created manually (via tag push), there was no mechanism to trigger a docs rebuild then the cached data remained stale indefinitely.
• How it works: After the image push and release notes steps complete, the workflow POSTs to a Netlify build hook with {"clear_cache": true}, which triggers a fresh build with no cached remote resources.

Why triggering per tag is safe

The after-tag-with-version.yaml workflow runs independently for each tag push. When using manual-patch-release with functions: "all", multiple tags are created in quick succession each triggering a separate Netlify build hook call.
This is handled gracefully by Netlify's context queue: when multiple builds are triggered on the same site in an identical deploy context, they enter a context queue.
When the current build completes, only the newest enqueued build runs and all intermediate ones are skipped. So even if 10+ tags fire simultaneously, at most 2 actual builds occur (the one in progress + the latest queued). No wasted build minutes, no race conditions.

Related Issue(s)

• N/A

Type of Change

• Bug fix
• New feature
• Enhancement
• Refactor
• Documentation
• Tests
• Other: ________

Checklist

• Code follows project style guidelines
• Self-reviewed changes
• Tests added/updated
• Documentation added/updated
• All tests and gating checks pass

AI Disclosure

• I have used AI in the creation of this PR.

If so, please describe how:
- Kiro used for this PR message and analysis

[netlify]

✅ Deploy Preview for krm-function-catalog canceled.

Name	Link
🔨 Latest commit	6a981d5
🔍 Latest deploy log	https://app.netlify.com/projects/krm-function-catalog/deploys/6a4f6d49ba72e80008f5d31c

[Copilot]

Pull request overview

This PR updates the release-tag GitHub Actions workflow to trigger a Netlify documentation site rebuild after a function release tag is pushed, ensuring the docs site refreshes cached GitHub API data used to render the function catalog.

Changes:

• Adds a post-release workflow step that POSTs to a Netlify build hook to force a rebuild with cleared cache.

---

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

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

[Catalin-Stratulat-Ericsson]

This is very nice. i wonder if we could also leverage something like this but for the porch documentation site so that the install version we give e.g. install version tag could be auto updated on every new release we make in the docs also as right now we have to manually update it and speaking of which we should propably do so considering it states to install 1.5.7 right now... porch install

[aravindtga]

This is very nice. i wonder if we could also leverage something like this but for the porch documentation site so that the install version we give e.g. install version tag could be auto updated on every new release we make in the docs also as right now we have to manually update it and speaking of which we should propably do so considering it states to install 1.5.7 right now... porch install

Yes, this is feasible. we already have the building blocks in place across repositories. In kpt, we resolve the latest version from git tags https://github.com/kptdev/kpt/blob/main/documentation/Makefile#L19, and we can adapt the porch docs to follow the same pattern.
We'd then use the same Netlify build hook approach from this PR to trigger documentation rebuilds on each release. Note that porch has both Porch API and porch Server/controller releases, so the trigger logic would need to account for both.