auto bump version in banner.go from previous tag

[dogancanbakir]

This PR bumps the version in the internal/runner/banner.go from the previous tag. Closes #91.

[tarunKoyalwar]

also to auto bump version in banner while creating release i think we can use set ldflags in gorelease config (ref: https://goreleaser.com/customization/builds/#passing-environment-variables-to-ldflags)

possible implementation

• get tag value from GITHUB_REF
• set it as env variable
• use that env variable in .goreleaser.yaml file with ldflags(ref: https://goreleaser.com/customization/builds/#passing-environment-variables-to-ldflags)

what do you think ??

[dogancanbakir]

@tarunKoyalwar The first two tasks on the list are completed along with additional logical steps. The final task can be utilized to enhance the script.

[Mzack9999]

I tried testing by forking your fork, but testing becomes quite challenging as GH doesn't let me create a PR. As @tarunKoyalwar pointed out, you probably need to commit after bumping the version in the go file. I think you need to do the following:

• Add a git commit step after bump
• Merge your auto_bump_version branch into your main
• Test creating tag releases and check if the version in the go file matches and gets bumped up

[Mzack9999]

To ensure it works, can we try to decrease the autorelease interval in your fork and see if the version is effectively bumped by +1 in Z (vX.Y.Z)?

(I saw some inconsistency in dogancanbakir@011f7ab)

[dogancanbakir]

I did, actually, but on a different branch. That commit was a mistake, so please ignore it. I created a tag 0.1.3 on my fork and ran the workflow and this is the commit it generated dogancanbakir@00b9c79.

[tarunKoyalwar]

testing this PR by forking . not sure about the reason
but version bump is corrupted i.e
changes v1.0.9 -> v..1

tarunKoyalwar@00b4b7b

i think we should have chosen to create a simple go program . with go ast and semver libraries now i think that would have been more stable since semver lib already implements and covers all edgecases related to version handling (cc : @Mzack9999 )

[dogancanbakir]

It sets it to v..1 because it first gets the previous tag and then increases the version. In your case, you needed the tag (tarunKoyalwar@cddcb7e). I agree and -realized now- that it would be better to use a well-tested and maintained tool instead of relying on a custom bash script. I'll try to implement it in go.

[Mzack9999]

lgtm! Great suggestion @tarunKoyalwar and implementation @dogancanbakir

Since this looks quite generic and useful what do you think about moving it to the https://github.com/projectdiscovery/utils package under scripts with readme containing instructions?

Example: https://github.com/Mzack9999/cdncheck/actions/runs/5644906529/job/15289638505

[dogancanbakir]

@Mzack9999, Yes, I was thinking the same. I'm on it.

[tarunKoyalwar]

yeah , i think it is definetly worth moving to utils .
projectdiscovery/utils#218 (review)

we can gather all such useful one use scripts and when we have enough of them we can put all of them in pd-bot (cc: @Mzack9999 )

[ehsandeep]

Requesting changes to make use of projectdiscovery/utils#218

[tarunKoyalwar]

lgtm !

tarunKoyalwar@b2e72ff