Semi-automatically handle version bumping inside padd.sh

[PromoFaux]

By submitting this pull request, I confirm the following:

• [x] I have read and understood the contributors guide, as well as this entire template.
• [x] I have made only one major change in my proposed changes.
• [ ] I have commented my proposed changes within the code.
• [x] I have tested my proposed changes, and have included unit tests where possible.
• [x] I am willing to help maintain this change if there are issues with it later.
• [x] I give this submission freely and claim no ownership.
• [x] It is compatible with the EUPL 1.2 license
• [x] I have squashed any insignificant commits. (git rebase)

---

What does this PR aim to accomplish?:

Prevents us from having to ask users to update the version string inside padd.sh before we accept a pull request.

It also allows us to merge in several pull requests before we decide to release a new version.

After merging this PR, releasing a new version will work as follows:

• Create a new release and give it a tag. e.g v3.5.4
• Merge PR created by the action

Here it is in action on my fork:

https://github.com/PromoFaux/PADD/releases/tag/v10001.0.0

https://github.com/PromoFaux/PADD/runs/5260069318?check_suite_focus=true

https://github.com/PromoFaux/PADD/pull/4

[subnut]

Looking at past releases, it looks like almost every time a commit is made, the version is bumped.

So, I would suggest this workflow -

• Workflow 1:
  on: commit check

  • if the latest commit changes padd.sh
  • if the latest commit does not have a tag associated with it

  If both conditions are true, create a tag by bumping 0.0.1 and push the tag. (The tag should be associated with the latest commit by default)

• Workflow 2:
  on: push check if the latest tag has a Github Release associated with it. If not, create a Release.

If this workflow is implemented, we can manually override the auto-tag functionality by creating the tag ourselves before pushing/merging to master branch. (Useful in case of major version bumps, like 0.x or x)

---

@yubiuser The above suggestion should avoid the issue you mentioned here, right?

[subnut]

Taken from https://github.com/subnut/nvim-ghost.nvim/blob/main/.github/workflows/create_release.yaml
Creates a GitHub Release when a new tag (of the format v*) is pushed -

name: Create Release
on:
  push:
    # Sequence of patterns matched against refs/tags
    tags:
      - 'v*' # Push events to matching v*, i.e. v1.0, v20.15.10

jobs:
  create:
    name: Create Release
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      - name: Create Release
        id: create_release
        uses: actions/create-release@v1
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} # This token is provided by Actions, you do not need to create your own token
        with:
          tag_name: ${{ github.ref }}
          draft: false
          prerelease: false

[yubiuser]

Looking at past releases, it looks like almost every time a commit is made, the version is bumped.

You're right but I would prefer not to go on like this. I only did this to keep old and new installations in sync. Otherwise some users with version 1.2.3 would have had other code than users newly downloading PADD with the same version.

Actually, I would prefer to have a release model similar to the once we have in the other repos: collect PRs in a development branch and at some point in time do a new release. Right before release one could bump the version (maybe the changes are bigger than 0.0.1). There would also be no need for fancy GH actions. In my mind this would be much simpler process.

[yubiuser]

I looked at this PR again after we switched to a release model using a development branch. The best workflow would be: Collect PRs in the development branch, at a certain point in time create a release draft with the next tag. This triggers a workflow that will PR the new version string in PADD.sh against development. Release.

Unfortunately, github's on: release does not trigger on drafts.... https://stackoverflow.com/questions/67791130/github-actions-trigger-on-creation-of-draft-of-github-release https://github.com/community/community/discussions/7118