Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Comments on GitHub action triggered by somebody else's repository
Parent
GitHub action triggered by somebody else's repository
Consider the following situation:
-
I have a GitHub repository for a LaTeX package: https://github.com/samcarter/beamertheme-spectrum
-
This LaTeX package depends on a class, for which somebody else has a GitHub repository: https://github.com/josephwright/ltx-talk
To make sure that my package stays compatible with the development of the class, I'd like to regularly run a GitHub Action in my repository to test this. At the moment, I run it on a schedule once a week:
name: Check with current ltx-talk
on:
schedule:
- cron: '47 13 * * 3'
Is it somehow possible to trigger this action based on events in the ltx-talk repository? For example every time a new version gets released or for every commit? I've read about repository_dispatch, but it seems this would require changes in the triggering repository.
In case it helps, I also have a fork of the ltx-talk repository, which is automatically kept up-to-date using Probot Pull.
Post
The following users marked this post as Works for me:
| User | Comment | Date |
|---|---|---|
| samcarter | (no comment) | Nov 9, 2025 at 13:10 |
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.
4 comment threads