feat: Add reusable workflow to sync branches and tags

[bthomee]

This change ports the sync-branches-tags workflow over to this repo, turning it into a reusable workflow. A test workflow is added to confirm that the dry-run, regular, and force behavior work as expected, using the https://github.com/XRPLF/actions-sync-test-src and https://github.com/XRPLF/actions-sync-test-dst repositories.

To enable testing, the original workflow had to be modified so it could access local scripts and actions when called from a different repo.

To keep the testing workflow as concise as possible, the following helper actions are introduced or updated:

• clone-repo
• configure-git
• configure-github-app (updated to not configure git anymore; callers who need it can use the action above)
• decrypt-token
• encrypt-token

The latter two actions are necessary to pass the GitHub App token between different jobs via GPG encryption, as GitHub Actions will otherwise not let you pass a secret between jobs.

[Copilot]

Pull request overview

Ports a branch/tag synchronization workflow into this repository as a reusable workflow_call workflow, along with bash scripts to perform the git operations and a CI workflow intended to test dry-run, normal, and force-sync behaviors.

Changes:

• Add reusable workflow .github/workflows/sync-branches-tags.yml to sync selected branches (matrix) and then tags.
• Add bash scripts to sync branches/tags using authenticated remotes and safe force semantics (--force-with-lease).
• Add a test workflow .github/workflows/test-sync-branches-tags.yml to exercise dry-run, regular sync, and force overwrite flows.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 9 comments.

Show a summary per file

File	Description
.github/workflows/test-sync-branches-tags.yml	Adds an end-to-end workflow to validate dry-run/normal/force sync behavior between two test repos.
.github/workflows/sync-branches-tags.yml	Introduces a reusable workflow_call entrypoint that runs branch sync in a matrix and tag sync after branches complete.
.github/scripts/sync-tags.sh	Implements tag synchronization logic including dry-run and force-with-lease overwrite.
.github/scripts/sync-common-functions.sh	Adds shared helpers for authenticated remotes and working repo setup/validation.
.github/scripts/sync-branches.sh	Implements branch synchronization logic including fast-forward, dry-run, and force-with-lease overwrite.

Comments suppressed due to low confidence (6)

.github/workflows/test-sync-branches-tags.yml:92

• This workflow clones the same repo name multiple times across steps. Because the workspace persists between steps, a later gh repo clone ${REPO} will fail if ${REPO} already exists from an earlier step. Remove the directory (or clone into a unique temp dir) before cloning.

          gh repo clone ${REPO}
          cd ${REPO}

.github/workflows/test-sync-branches-tags.yml:120

• This workflow clones the same repo name multiple times across steps. Because the workspace persists between steps, a later gh repo clone ${REPO} will fail if ${REPO} already exists from an earlier step. Remove the directory (or clone into a unique temp dir) before cloning.

          gh repo clone ${REPO}
          cd ${REPO}

.github/workflows/test-sync-branches-tags.yml:138

• This workflow clones the same repo name multiple times across steps. Because the workspace persists between steps, a later gh repo clone ${REPO} will fail if ${REPO} already exists from an earlier step. Remove the directory (or clone into a unique temp dir) before cloning.

          gh repo clone ${REPO}
          cd ${REPO}

.github/workflows/test-sync-branches-tags.yml:163

• This workflow clones the same repo name multiple times across steps. Because the workspace persists between steps, a later gh repo clone ${REPO} will fail if ${REPO} already exists from an earlier step. Remove the directory (or clone into a unique temp dir) before cloning.

          gh repo clone ${REPO}
          cd ${REPO}

.github/workflows/test-sync-branches-tags.yml:179

• This workflow clones the same repo name multiple times across steps. Because the workspace persists between steps, a later gh repo clone ${REPO} will fail if ${REPO} already exists from an earlier step. Remove the directory (or clone into a unique temp dir) before cloning.

          gh repo clone ${REPO}
          cd ${REPO}

.github/workflows/test-sync-branches-tags.yml:192

• This workflow clones the same repo name multiple times across steps. Because the workspace persists between steps, a later gh repo clone ${REPO} will fail if ${REPO} already exists from an earlier step. Remove the directory (or clone into a unique temp dir) before cloning.

          gh repo clone ${REPO}
          cd ${REPO}

---

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

[Copilot]

Pull request overview

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

Comments suppressed due to low confidence (1)

.github/workflows/sync-branches-tags.yml:104

• Same issue as the branch job: this job checks out the caller repository but then runs .github/scripts/sync-tags.sh and uses ./decrypt-token, which won’t exist when this workflow is invoked from another repository.

      - name: Checkout repository
        uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0

[mathbunnyru]

Overall, LGTM, some naming can be done slightly better - I haven't marked all places, but it's nit

[mathbunnyru]

Ah, this is important - will it work in a PR done from a fork?
Same question about other pull_requests you add

[bthomee]

It depends on what you're trying to accomplish. The workflow currently only accepts GitHub App credentials, for which it then generates a GitHub token; the owner is required to be the same as a GitHub App is installed in an org, so you can only sync repos within the same org. My understanding is that even if the GitHub App is public and you can install it in multiple orgs, then you'd still end up with a different client ID and private key, so you'd still not be able to sync across orgs.

If this reusable workflow is supposed to be callable from a fork, then I can add an additional gh_token as input - if provided it will use that one instead. Personal access tokens can be used to sync across orgs - the workflow will be able to sync whatever the account has access to. Note that the script that the workflow calls only uses the GitHub token and that works for both PATs and GitHub Apps (since the token is fetched on demand for the GitHub App).

If you mean whether the test sync branches and tags workflow will work (or at least no nothing instead of failing) when someone clones the repo, then I'm pretty sure the answer is "no" since it's unlikely someone else will have (i) also cloned the same source and destination test repos, and (ii) set up their own GitHub App and added the client ID and private key as secrets. Would adding if: ${{ github.repository == 'XRPLF/actions' }} to each job be sufficient?

[mathbunnyru]

I'm trying to have a setup, which won't break if I create a PR from my branch.
And which would work fine in my fork on schedule.

By "work fine" I mean it should run all steps which don't require any additional configuration in a fork.
So, if it requires some repos to exist, secrets and something like that - then don't run these steps

[bthomee]

Done, added if: ${{ github.repository == 'XRPLF/actions' }}.

The last job uses if: ${{ github.repository == 'XRPLF/actions' && always() }} - not sure if that actually will work, one way to find out.

[bthomee]

It worked 🙂

[mathbunnyru]

Done, added if: ${{ github.repository == 'XRPLF/actions' }}

When creating a PR from fork, it'll also be true, because github.repository is set to the base repository — i.e., the repo the PR is being opened against — not the fork

So, this gate is actually if true
Note - this PR is made not from fork, so we don't know what would actually happen in a fork

[bthomee]

Done. Note that I borrowed the original logic from existing test scripts. The test-pre-commit-autoupdate.yml and test-build-multiarch-image.yml might need to be updated similarly.

[mathbunnyru]

No, they work fine.

Does your PR, if merged into a fork, will run fine on a push event inside that fork?

[bthomee]

I'll admit that I'm not overly familiar with how GitHub Actions runs in forks. Something worth trying out after it's merged.