Updated workflow

[ozh]

I came up with a better workflow for check-yourls-release.yml :

It :

• Files a new issue when there is a new release (because simply committing won't trigger the test workflow)
• Disables running on every push and PR, this is useless since it's already on the other workflow

Updated workflow :

name: Check if new YOURLS release

on:
  # Run every Monday
  schedule:
    - cron:  '37 13 * * 1'
  # Also allow manually triggering the workflow.
  workflow_dispatch:

jobs:
  get-version:
    runs-on: ubuntu-latest
    steps:

      - name: Checkout code
        uses: actions/checkout@v3
        
      - name: Fetch release version
        run: |
          curl -sL https://api.github.com/repos/yourls/yourls/releases/latest | \
          jq -r ".tag_name" > .github/.latest-yourls-release
          
      - name: Commit and push if change
        id: commit-if-new
        run: |
          git diff
          git config user.name "github-actions"
          git config user.email "[email protected]"
          git add -A
          git commit -m "New YOURLS release" && echo "::set-output name=NEWVERSION::new"
          git push
          
      - name: Create Issue on new release
        if: steps.commit-if-new.outputs.NEWVERSION == 'new'
        uses: mrdoodles/[email protected]
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
          title: New YOURLS release !
          body: |
            There is a new YOURLS release available: https://github.com/YOURLS/YOURLS/releases

            Please check if your plugin is compatible with this release !

Cheers !

[dgw]

What about committing to a specific new-yourls-version branch and then opening a PR for that branch if one isn't already open? If a PR is already open, just push a commit to that same branch to trigger the workflow again. Maybe this approach still won't trigger the tests workflow, because of GHA limitations? (Haven't studied this in depth.)

That aside, ideally this workflow would update the existing "new release" issue if one is already open, rather than creating another. Might be an edge case, but YOURLS wouldn't be the first project to publish multiple versions in quick succession after a packaging mishap or other oversight makes a version unusable for some reason.

No idea if that's actually happened in recent YOURLS history (don't think so), but planning ahead is 👌.

[ozh]

Yes that would be a very valid option, yet a bit out of the scope of my documentation for which I use your plugin as a test case

My goal is to provide a simple workflow example, and indeed my previous assumptions were that simply committing would trigger tests, which turned out false, just like filing a PR as you suggest (by design, workflows can't trigger workflow, you have to work around with apps or personal tokens)

So, to sum up, just pointing out that the workflow as I initially wrote it won't do much :)

[dgw]

Sigh. I understand why GitHub did things this way, but it's still frustrating.

Feel free to make a PR with whatever solution you think is best. If you can't do the "update existing issue" part, don't worry about it.

[ozh]

In my opinion given the pace of development of YOURLS and most plugins, the best is the simple workflow I described above.

(Can't PR, I deleted my fork)

[dgw]

(Can't PR, I deleted my fork)

(Fork again?)