Fix #74 - Create a plugin release GitHub Action #94
Conversation
|
Something like this GitHub Action within 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" }' |
.github/workflows/update-plugin.yml
Outdated
| env: | ||
| PLUGIN_NAME: ${{ github.event.inputs.repository }} | ||
| run: | | ||
| RELEASE=$(curl -s https://api.github.com/repos/${{ github.repository_owner }}/${PLUGIN_NAME}/releases/latest | grep tag_name | cut -d '"' -f 4) |
There was a problem hiding this comment.
This assumes plugin code is in Github, uses tagging and has the same version numbering scheme.
There was a problem hiding this comment.
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.)
There was a problem hiding this comment.
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.
|
Because not everyone has the same setup or conventions, my initial though is to add this to docs, not into the repo code. |
This is the reason the GitHub Action raises the change as a PR onto the fork of the registry rather than the
Docs would make sense, but adding the action into 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/[email protected]
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) |
|
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. |
url and vers are option
|
Optional url and version parameters added:
|
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
Documentation and Compatibility
Documentation has not been updated as part of this PR.
Checklist