GitHub action triggered by somebody else's repository

Facing a somewhat similar situation, I took mr Tsolder's suggestion of looking into submodules.

In my case, it was fine to keep the remote project as a folder in my local clone, but I think it still works if you don't want the copy in your worktree. Just git submodule deinit Joseph Wright's repo.

Then, I made a Dependabot instruction to make a PR if it detected that the remote project had updates:

version: 2
updates:
  - package-ecosystem: gitsubmodule
    schedule:
        interval: daily
    directory: /

That was the flow I wanted to make sure that my code could handle the dependency before pushing to master: running CI and adding my own commits to the PR if needed.

But if you're happy to push submodule changes directly, you can do that with a GitHub Action:

name: Update submodules
on:
  schedule:
    - cron:  '0 * * * *'

jobs:
  update_submodules:
    name: Update submodules
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
      with:
        submodules: recursive
    - name: Update submodules
      id: update
      run: git submodule update --remote --recursive 
    - name: Add and commit files
      run: |
        git add .
        git config --local user.email "[email protected]"
        git config --local user.name "GitHub Action"
        git commit -m "Update submodules at $(date "+DATE: %Y-%m-%d TIME: %H:%M:%S")"
      if: ${{ steps.status.outputs.status }}
    - name: Push changes
      uses: ad-m/github-push-action@master
      with:
        github_token: ${{ secrets.GITHUB_TOKEN }}
        branch: main
      # if: ${{ steps.status.outputs.status && github.event_name == 'push' }}

The submodule approach doesn't eliminate a cron completely (see the schedule key in the two YAML snippets above), but it's no more delay than triggering actions from your Probot-synced fork.

posted 2 months ago

CC BY-SA 4.0

2mo ago

Michael‭

1361 reputation 6 34 145 98

None of the below is tested, but logically should work.

1. In your fork, configure probot pull to use the merge strategy instead of its default hardreset. A git merge will mix your changes with the upstream changes, whereas hardreset will 'reset' your fork to look like the upstream. That would be bad since we're adding new files. This involves adding a new file .github/pull.yml to the default branch of your fork (in this case main). Docs

   version: "1"
   rules:
     - base: main
       # Not fully sure if this is correct but its either this
       # or 'josephwright/ltx-talk:main'
       upstream: josephwright:main
       mergeMethod: merge
       # Reading the docs, I think this stops merges that have
       # conflicts. We wouldn't expect conflicts in this strategy,
       # but if they do occur we want to be notified through the
       # failure so we can address it. Flip to true if it's giving
       # you grief.
       mergeUnstable: false
   

2. In your fork, add a new workflow in the .github/workflows/ folder that triggers off commits on the main branch. This workflow will use repository_dispatch to trigger the workflow in all other repositories. Docs

   name: trigger-remote-repo
   run-name: Triggering action in remote repository
   on:
     push:
       branches:
         - main
   jobs:
     trigger-remote:
       runs-on: ubuntu-latest
       steps:
         - name: Dispatch event to remote repository
           uses: peter-evans/repository-dispatch@v4
           with:
             token: ${{ secrets.PAT }}
             repository: samcarter/beamertheme-spectrum
             event-type: any-old-event-name
   

   • Note this requires you to set up a personal access token (technically you should use fine-grained-access tokens, but that's something I'd go back and fix after getting everything working first.). Then store that token in secrets with the name PAT. I would use the organizational secrets which should make that secret available to all your repositories. But if that doesn't work store it directly in the forked repo's secrets.

3. In your personal repository, create/update your workflow to respond to that event. Example

   name: update-from-upstream
   run-name: An event occurred in the upstream repository
   
   # This is the relevant bit. Make sure the event type matches
   # the name you used in the fork.
   on:
     repository_dispatch:
       types: [any-old-event-name]
   
   # Do whatever you need to. I'd assume this'd be the same job
   # as in the cron workflow you already made.
   jobs:
     respond-to-event:
       runs-on: ubuntu-latest
       steps:
         - shell: bash
           run: |
             echo "Doing whatever I needed to do."
   

posted 2 months ago

CC BY-SA 4.0

2mo ago by Michael‭

jmathew‭

355 reputation 0 9 33 11