Adds workflow to automatically dispatch updates to dependent GMOD repos

[carolinebridge]

When a new version of jbrowse-components is published, this workflow will trigger and will dispatch an event to dependent GMOD workflows.

Relevant permissions in this repo, and dependent repos:

• Workflow permissions > read and write permissions
• Actions secrets > repository secrets > ACTIONS_KEY === github personal access token

A publish action MUST be invoked for this workflow to trigger / work (because it needs the version from the publish action)

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (a386d3f) 63.02% compared to head (663da1d) 63.02%.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4159   +/-   ##
=======================================
  Coverage   63.02%   63.02%           
=======================================
  Files        1067     1067           
  Lines       31102    31102           
  Branches     7428     7428           
=======================================
+ Hits        19602    19603    +1     
+ Misses      11331    11330    -1     
  Partials      169      169           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[carolinebridge]

For dependent example repos, this file must be added to .github/workflows/

auto_deploy.yml

name: Receive dispatch (deploy)

on:
  repository_dispatch:
    types:
      - auto_publish

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Upgrade and deploy
        run: |
          yarn upgrade && yarn deploy

This will trigger automatically when jbrowse-components is published and run the upgrade and deploy ops in those dependent repos.

[cmdcolin]

I think this is a great proof of concept but I might say we don't go forward with it. i think just enhancing our shell script for release might be preferable...

to that end, might suggest closing this. then the (optional, but enhancement-style) remaining steps would be to add dash_jbrowse and JBrowseR to shell script in e.g. embedded_demos/ release script.

[cmdcolin]

my general reasoning: with the shell script, you have single point of failure (easy error reporting: the script crashed in a single place in your terminal when you're running it, instead of monitoring the CI on our 10+ demo repos and dash_jbrowse and JBrowseR), and can more easily just do manual steps to trigger retries instead of relying on pushing commits to trigger CI/CD.

using the manual deploy steps is of course anathema to modern CI/CD dogma but...i think it may work better for our complex release system