Auto release new minor versions

[zen0bit]

Major version bump should be done manually

[zen0bit]

Preview

[mckaygerhard]

:+1: great! hey, the trigger is? i mean when this "auto" release tag will be deploy? witch action does the triggering ?

[mckaygerhard]

i mean you put

on: 
  push:
    branches:
      - master

this has a problem, on any commit+push we will have a release no matter is there is a test failing or not!

so your proposal maybe is : have a stable branch for release and a develop branch ?

[vaisarger]

I agree with @mckaygerhard ...

"Automated" release naming would be done even in case there is a test failing, or anything else failing, that is, e.g., I don't want a new release (at least, I don't want it yet ).

[zen0bit]

👍 great! hey, the trigger is? i mean when this "auto" release tag will be deploy? witch action does the triggering ?

trigger could be whatever you want, could run only after success test.. (change needed)

Or bind to tag (major minor patch no-release)

automated releases could be named like you want (marked as you want pre-release, latest etc)

so your proposal maybe is : have a stable branch for release and a develop branch ?

That is good practice

[vaisarger]

So, if I've got it properly, when I type in my terminal: git push github master

then Github would create, say, the version 12.0.7 of EBG, automatically?

Am I correct ?

[zen0bit]

12.1.0

in this PR could be changed 12 major .1 minor

don't know what patch do differently

[zen0bit]

Or you can use bash in github action for anything you want.. (on my learning list)

[vaisarger]

So, my friend... We would have only 9 possible changes before major version change...

This project is not so "live & working", anyway I see this as a limitation...

@mckaygerhard what do you think about?

[zen0bit]

12.99.0

[zen0bit]

its scripting, anything isn't set in stones (i hope) anything is possible, you just need figured out how could be changed...

only boundary is your imagination right?

[vaisarger]

12.99.0

Oh ! right ! :P

Or you can use bash in github action for anything you want..

Namely, you are saying that, e.g. for a potential 12.0.7, I still could do pushing by a new tag from my terminal ?

anything is possible, you just need figured out how could be changed...

I absolutely agree ! you know... I'm just trying to realize because I'm not at all Github expert: only for this reason!

[zen0bit]

So, my friend... We would have only 9 possible changes before major version change...

you are not! we are working with computers which can oprate with anything we will give them. (not only 1-9)

This project is not so "live & working", anyway I see this as a limitation...

@mckaygerhard what do you think about?

[vaisarger]

I'm seriously considering it...

With this auto-versioning... Is still possible changing version manually by tag, from terminal?

[zen0bit]

12.99.0

Oh ! right ! :P

Or you can use bash in github action for anything you want..

Namely, you are saying that, e.g. for a potential 12.0.7, I still could do pushing by a new tag from my terminal ?

sure (not yet get used to githubcli except pushing/pulling everything done on github webui.)

or can be triggered only manually. so one click for you with version change (which one you choose) with complet changelog in few seconds

or better don't ask what you can, tell what you want...

anything is possible, you just need figured out how could be changed...

anything is possible, you just need figured out how could be changed...

I absolutely agree ! you know... I'm just trying to realize because I'm not at all Github expert: only for this reason!

Me to, just bit more experienced, since working against actions often 😃

[vaisarger]

I hope my question will not mind you... (really):

If I possibly would change my mind about auto-versioning, how could I come back?

[zen0bit]

that minor major patch no0release could be also override with appropriate label in PR name

look on actions READMEs in repo itself... action-automatic-release release-action action-gh-release

If I possibly would change my mind about auto-versioning, how could I come back?

just delete yml file or change trigger in action to worflow_dispatch only (manual trigger)

[zen0bit]

don't ask what you can, tell what you want...

[vaisarger]

just delete yml file

And where will be that file? In same location of LICENSE file ?

[zen0bit]

look at 1 changed file in this PR

under .github/workflows/any-name-you-want.yml

PS: added some comments inside file to better understand..

[vaisarger]

look at 1 changed file in this PR PS: added some comments inside file to better understand..

Thank you very much, now is more understandable! :P

Still I didn't understand where will go that .yml file in EBG tarball...

[zen0bit]

nowhere. its hidden file just for github.

it's why is under .github/

(like github dotfile)

[mckaygerhard]

I'm seriously considering it...

With this auto-versioning... Is still possible changing version manually by tag, from terminal?

@zen0bit change the script to use tags.. that solve the problem for @vaisarger so he can decide when release using tag marks

[vaisarger]

nowhere. its hidden file just for github.

it's why is under .github/

I don't have that directory... where is ? (sorry )

[mckaygerhard]

nowhere. its hidden file just for github.

it's why is under .github/

I don't have that directory... where is ? (sorry )

ls -la will show you.. any dir with dot as prefix will be hidden in linux

also if you dont have the changes from him will not have such change and directory! dont worry

such directory .github/* is only for github actions.. nothing more..

by the way i posted a message before for him! maybe will help to you

[zen0bit]

Or you can create release[anyname] branch and if you push changes there, that will trigger new release..

[zen0bit]

nowhere. its hidden file just for github.

it's why is under .github/

I don't have that directory... where is ? (sorry )

sure, create only if needed

[zen0bit]

I added a lot comments etc. to better see how github workflow works.. Now is more a like template and also "Hello world" to see easy use of bash...

[zen0bit]

Just define what exactly wanna achieve and your current workflow/staff used

[mckaygerhard]

Just define what exactly wanna achieve and your current workflow/staff used

yes looks good to me!

[vaisarger]

Sorry guys, we Open Source developers have a (tough) life also... :P I would ask you to confirm two things about this PR:

1) If merged, a .github dir will appear in my local project directory?

2) with last change, only if I set a new tag (typing in terminal e.g.: git tag -a 13.0 -m "Brand new EBG version" ), github will trigger a new version... But, typing only: git push github master then no new version will be created?

Thank you for your patience...

[zen0bit]

1) If merged, a .github dir will appear in my local project directory?

yes

2) with last change, only if I set a new tag (typing in terminal e.g.: git tag -a 13.0 -m "Brand new EBG version" ), github will trigger a new version...

On line 21 tag is set to tags: [ 'v*.*' ] So only if match this pattern...

You can look at my repo where I am trying that. (WebUI) In actions and releases you see..

Used this command to add and push git tag -a v0.8.0 -m "Brand new EBG version test" && git push gh v0.8.0 (I named my REMOTE gh since on github)

tag must match next elease number, because action will create number depending on last number not that you provided..

But, typing only: git push github master then no new version will be created?

yes

Here is full yaml file from author:

# action.yml
name: 'Tag/Release on Push Action'
description: 'Creates a Tag/Release on Push. Generates Release Notes. Customizable with Pull Request Labels'
author: 'rymndhng'
inputs:
  bump_version_scheme:
    description: 'The bumping scheme to use by default. One of minor|major|patch|norelease'
    required: true
  release_body:
    description: "Additional text to insert into the release's body."
    required: false
  tag_prefix:
    description: "Prefix to append to git tags. To unset this, set version_prefix to an empty string."
    required: false
    default: 'v'
  release_name:
    description: |
      Name of the release. Supports these template variables:

        <RELEASE_VERSION> the version number, e.g. "1.2.3"
        <RELEASE_TAG>     the git tag name, e.g. "v1.2.3"
    required: true
    default: '<RELEASE_TAG>'
  max_commits:
    description: "Maximum number of commits to add to release body"
    required: false
    default: 50
  use_github_release_notes:
    description: "When set to 'true', uses Github's Generated Release Notes instead of this plugin's release notes"
    required: false
    default: "false"
  dry_run:
    description: "When set to 'true', will compute the next tag, but will not create a release."
    required: false
    default: "false"
outputs:
  tag_name:
    description: 'Tag of released version'
  version:
    description: 'Version of release'
  body:
    description: 'Github Release Body in Text'
  upload_url:
    description: 'Github Release Upload URL'
runs:
  using: 'docker'
  image: 'Dockerfile'
branding:
  icon: 'award'
  color: 'blue'

And repo for README etc...

[vaisarger]

Ok. Now...

I usually use these commands to add and push: git tag -a "13.0.0" -m "Brand new EBG version" && git push --tags github master

...

After this PR, what will the list of commands look like? Maybe this: git tag -a "v.13.0.0" -m "Brand new EBG version" && git push master v.13.0.0

???

[mckaygerhard]

I usually use these commands to add and push: git tag -a "13.0.0" -m "Brand new EBG version" && git push --tags github master ... After this PR, what will the list of commands look like? Maybe this: git tag -a "v.13.0.0" -m "Brand new EBG version" && git push master v.13.0.0

umm now makes sense to me your questions. . @zen0bit needs a letter like "v" to discern if the tag is to make a release, but you do not use letters and use only numbers.. umm i have some ideas to improve your PR @zen0bit but i will check it in deep only this weekend..

[mckaygerhard]

@vaisarger i tested and if you want to be release only on tags we can change the behaviour but liked the idea!

[zen0bit]

look at second PR and again at my repo to what happened...

[zen0bit]

we can close this I think...

[mckaygerhard]

seems you works so much @zen0bit yeah. close this and let @vaisarger check #36 that it follows the schema number as X.Y.Z for tags releases

[zen0bit]

Completed in #36