Fix #74 - Create a plugin release GitHub Action

[jason-fox]

---

name: Pull request
about: New Feature to allow workflow automation of plugin releases.

---

Description

This GitHub Action creates a PR to the user's fork of the DITA-OT registry and automatically adds a new release entry based on the checksum of the latest release. The expected work process is to review and merge the changes to a branch and then raise a PR on the upstream DITA-OT Registry

Motivation and Context

Fixes #74

How Has This Been Tested?

See #93 and Manual Actions. At the moment the release PRs have been generated via a manual trigger on the Registry fork but could be added as a GitHub Action on the plugins themselves.

Type of Changes

• New feature (non-breaking change which adds functionality)

Documentation and Compatibility

Documentation has not been updated as part of this PR.

Checklist

• My code follows the code style of this project.
  • https://github.com/dita-ot/dita-ot/wiki/Java-Coding-Conventions
  • https://github.com/dita-ot/dita-ot/wiki/XSLT-Coding-Conventions
  • https://github.com/dita-ot/docs/wiki/coding-guidelines
• I have updated the unit tests to reflect the changes in my code.

[jason-fox]

Something like this GitHub Action within my-org/org.my.plugin should raise PRs on my-org/registry

on:
  push:
    tags: '*'
jobs:
  raise-pr:
    name: Raise a PR on the DITA-OT registry fork
    runs-on: ubuntu-latest
    steps:
      - name: Invoke workflow in another repo with inputs
        uses: benc-uk/workflow-dispatch@v1
        with:
          workflow: Create Plugin Revision
          repo: my-org/registry
          token: ${{ secrets.PERSONAL_TOKEN }}
          inputs: '{ "Plugin Repository Name": "org.my.plugin", "Target Branch": "releases" }'

[jelovirt]

This assumes plugin code is in Github, uses tagging and has the same version numbering scheme.

[jason-fox]

Current iteration assumes that the plugin is indeed the result of a sem-ver release on a GitHub repo. The archive endpoint is more consistent than the releases/download - but the GitHub Action could be extended to look for the alternative (just add a flag with archive being the default.)

[jason-fox]

Fix d6e7c32 - you can now optionally add url and vers directly into the action and the PR will calculate the checksum. If not supplied the default is to curl for the latest release.

[jelovirt]

Because not everyone has the same setup or conventions, my initial though is to add this to docs, not into the repo code.

[jason-fox]

Because not everyone has the same setup or conventions

This is the reason the GitHub Action raises the change as a PR onto the fork of the registry rather than the dita-ot/registry itself. The PR itself needs to be reviewed by a human to ensure that things like the tags, texts and dependencies are correct. This is the reason the Action uses ${{ github.repository_owner } in its calls.

my initial thought is to add this to docs, not into the repo code.

Docs would make sense, but adding the action into dita-ot/registry helps downstream users like me in one very specific way. When I want to add a new release, the first thing I do is to sync with the upstream repo. If the GitHub Action Generate Plugin Release can't be found on the default branch of the dita-ot/registry, I can't invoke it manually on my fork.

Actually I would also consider adding a Sync-to-Upstream action to keep my fork up-to-date as well e.g.:

name: Sync to Upstream

on:
  workflow_dispatch:

jobs:
  sync_with_upstream:
    runs-on: ubuntu-latest
    name: Sync HEAD with upstream latest

    steps:
    # Step 1: run a standard checkout action, provided by github
    - name: Checkout HEAD
      uses: actions/checkout@v2
      with:
        ref: master
    
    # Step 2: run this sync action - specify the upstream repo, upstream branch to sync with, and target sync branch
    - name: Pull upstream changes
      id: sync
      uses: aormsby/Fork-Sync-With-Upstream-action@v2.1
      with:
        upstream_repository: dita-ot/registry
        upstream_branch: master
        target_branch: master 

This again would need to be present in the upstream repo, even if it is never run (and would be a noOp anyway)

[jason-fox]

Looking at the JSON files, it looks like there is an even split between plugin developers using the archive endpoint and those using releases/download

{
 "url": "https://github.com/dita-community/org.dita-community.i18n/releases/download/version-2.0.1/org_dita-community_i18n_plugin_2.0.1.zip",
 "url": "https://github.com/dita-community/org.dita-community.i18n/releases/download/version-1.0.0/org_dita-community_i18n_plugin_1.0.0.zip",


  "url": "https://github.com/dita-ot/dita-ot/releases/download/3.3.4/org.dita.eclipsehelp-3.3.4.zip",
  "url": "https://github.com/dita-ot/org.dita.eclipsehelp/releases/download/3.4/org.dita.eclipsehelp-3.4.0.zip",

 "url": "https://github.com/dita-community/org.dita-community.pdf-page-break/archive/v1.0.0.zip",
 "url": "https://github.com/dita-semia/org.dita-semia.diff/archive/0.1.zip",
 "url": "https://github.com/dita-semia/org.dita-semia.image-convert/archive/v1.0.zip"
}

It would be a simple matter to tweak the bash to support some variants of releases/download in addition to archive.

[jason-fox]

Optional url and version parameters added: