Add release artifact sync workflow

[welteki]

Description

Adds a release artifact sync workflow for copying release binaries from an OCI artifact bundle into GitHub Releases.

The workflow can run nightly or through workflow_dispatch. When a tag is provided, it syncs that tag explicitly and overwrites matching release assets. Without a tag, it lists tags from ghcr.io/openfaasltd/inlets-pro-artifacts and only syncs releases that are missing from the public repository.

The release sync logic is kept in hack/sync-release-artifacts.sh so it can be tested locally with a source OCI artifact, target repository, and optional tag.

Motivation and context

This is part of a series of changes to automate publishing and release syncing between the private and public inlets-pro repositories.

How has this been tested

Tested the script locally against a public OCI artifact bundle and a test repository, including the explicit tag sync path and the no-tag skip path.

Also tested the workflow end-to-end through workflow_dispatch against a test repository. The run completed successfully and uploaded the expected release binaries and checksums.

[welteki]

The tag concern is understood, but in this repo there is no corresponding public commit for the private build. Public release tags are intentionally just anchors on the public default branch, so creating a missing release tag at the current public branch head is acceptable for this sync workflow.

[alexellis]

If the public repository intentionally lacks those git tags, the sync job needs a reliable source for the correct target commit and should create tags with --target rather than letting gh default to the current branch tip.

Not sure if there's something in this - but the public releases are not code-based - they're just buckets for uploads.

Maybe add a comment to help the review understand the intent.

[welteki]

Maybe add a comment to help the review understand the intent.

I added a comment in the code so that future reviewers can see why the concern is not really applicable here.

[reviewfn]

AI Pull Request Overview

Disclaimer: This review was generated by automated AI and may contain errors. Do not trust its outputs without human verification.

Summary

• Adds a scheduled and manually dispatched workflow to sync OCI-hosted release artifacts into GitHub Releases.
• Adds hack/sync-release-artifacts.sh to list source tags, create missing releases, and upload extracted artifacts.
• The no-tag path intentionally skips releases that already exist in the target repository.
• The implementation has a recovery gap if release creation succeeds but artifact upload fails.
• The workflow currently runs privileged release writes after fetching tooling from mutable references.
• The source OCI pull path appears unauthenticated, which may not work for a private GHCR artifact source.

Approval rating (1-10)

6/10. The approach is reasonable, but release recovery and privileged workflow hardening should be addressed before relying on this automation.

Summary per file

Summary per file

File path	Summary
.github/workflows/sync-release-artifacts.yml	Adds scheduled/manual workflow for syncing release artifacts.
hack/sync-release-artifacts.sh	Adds OCI tag listing, release creation, and asset upload script.

Overall Assessment

The PR is small and focused, but it introduces release-publishing automation with write access to the repository. The biggest functional issue is that a transient upload failure can leave an empty or incomplete release that future scheduled runs will permanently skip. The workflow should also avoid mutable third-party action/tool references while running with contents: write, and the source registry authentication path should be made explicit if the artifact image is private.

Detailed Review

Detailed Review

Findings

High: Incomplete releases can become permanently skipped after a partial failure

hack/sync-release-artifacts.sh:28-34 creates the target release before uploading assets, while hack/sync-release-artifacts.sh:53-57 skips every existing release in the normal no-tag sync path. If gh release create succeeds and gh release upload fails because of a transient network/API error, a bad archive, or a partial asset upload failure, the target release now exists but may have no assets or only some assets. The next scheduled run will see the tag in existing_releases and skip it forever unless someone manually reruns with that tag.

A safer pattern is to track whether the script created the release and delete it on upload failure, or make the scheduled path decide based on required assets rather than release existence alone. For example, the function could install a cleanup trap only for newly created releases until upload succeeds:

created_release=false
if ! gh release view "${source_tag}" --repo "${target_repo}" >/dev/null 2>&1; then
  gh release create "${source_tag}" --repo "${target_repo}" --title "${source_tag}" --notes "" >/dev/null
  created_release=true
fi

if ! gh release upload "${source_tag}" "${tmpdir}"/* --repo "${target_repo}" --clobber >&2; then
  if [ "${created_release}" = true ]; then
    gh release delete "${source_tag}" --repo "${target_repo}" --yes >/dev/null 2>&1 || true
  fi
  return 1
fi

High: Mutable action and tool references run with repository write permissions

.github/workflows/sync-release-artifacts.yml:13-28 grants contents: write, then runs alexellis/arkade-get@master and asks it to install crane: latest. Because both the action ref and the installed tool version are mutable, a compromised upstream branch, changed install script, or bad latest release would execute in a job that can create releases and overwrite release assets.

For release-publishing automation, pin the third-party action to an immutable commit SHA and pin crane to a known version, or install a pinned binary with checksum verification. This materially reduces the blast radius of a supply-chain issue in a workflow that has release write access.

Medium: Private GHCR source images will not be readable without explicit registry authentication

.github/workflows/sync-release-artifacts.yml:31-35 exports only GH_TOKEN for the GitHub CLI, and hack/sync-release-artifacts.sh:26 calls crane export without logging in to GHCR. If ghcr.io/openfaasltd/inlets-pro-artifacts is private, or becomes private because it contains proprietary release artifacts, this workflow will try to pull it anonymously and fail before any release sync happens. The default github.token for the public target repository is not automatically a cross-organization GHCR credential for openfaasltd.

Make the registry access model explicit. If the image is public, document that assumption in the workflow/script. If it is private, add the required permission and authentication step, such as crane auth login ghcr.io or docker/login-action with a token that has read:packages for the source package.

AI agent details.

Agent processing time: 1m43.43s
Environment preparation time: 3.088s
Total time from webhook: 1m49.604s