Deploy to another repository

[jhpratt]

I manage the time-rs organization, which has a website located at https://time-rs.github.io. The source for this is generated from two separate repositories: time-rs/time and time-rs/book. I would like to have a shared workflow that deploys to time-rs/time-rs.github.io, such that I can have a landing page (as is currently the case).

My attempt at doing this was to create a workflow to build everything from scratch, which works as expected. However, when trying to use it as a reusable workflow, it failed because it is trying to deploy it to the caller's GitHub pages. This is not what I want.

Would it be possible to add the ability to deploy the pages to another repository? I presume this would need a PAT, but that is acceptable to me. The alternative is using the branch-based method that I have been using for years, even if it is less than ideal.

[jhpratt]

The closest I can get to what I want seems to be triggering a manual dispatch via the API, but that does not permit the resulting status to be passed back in order to fail a job if necessary.

[jhpratt]

Through convoluted indirection, it is possible, though not 100% reliable.

name: Deploy

env:
  REPO: time-rs/time-rs.github.io
  WORKFLOW: build-website.yaml
  GH_TOKEN: ${{ secrets.WEBSITE_PUBLISHING }}

on:
  workflow_call:
  workflow_dispatch:

jobs:
  deploy:
    name: Deploy
    runs-on: ubuntu-latest
    permissions:
      actions: write

    steps:
      - name: Trigger deploy
        id: trigger
        run: |
          gh workflow run --repo ${{ env.REPO }} ${{ env.WORKFLOW }}
          sleep 3 # Let the run be created
          echo "RUN_ID=$(gh run list --repo ${{ env.REPO }} --json databaseId --workflow ${{ env.WORKFLOW }} --limit 1 | jq -r '.[0].databaseId')" >> "$GITHUB_OUTPUT"

      - name: Wait for deployment
        run: gh run watch --repo ${{ env.REPO }} ${{ steps.trigger.outputs.RUN_ID }} --interval 1 --exit-status

As I suspected, a PAT is necessary (that's secret.WEBSITE_PUBLISHING). The sleep is necessary because it's possible that the spawned run isn't present by the time the next query is run. It is possible that multiple workflows could be triggered in this short timespan, resulting in the wrong workflow ID being used.

Given the complexity, indirection, and lack of reliability, it would be wonderful if this could be implemented natively.