k-phoen / semver-release-action Goto Github PK

It would be nice to have a pull request body added to a release, not just the commit messages

It would be cool to allow specifying a default semver version bump in case when no labels are provided in a PR.

Eg: default_version: patch, so that patch version gets bumped by default. If a user doesn't provide default_version then a label is required as before. If default_version is provided, but a pr has a different version label eg minor, then a pr's label gets priority.

Eg check this pr cbrwizard/cbrwizard.com#47

To reproduce:

1. Open a pr
2. Close it without merging
3. Reopen it (or even worse: open a new pull request for the same branch).

It results in failing checks being displayed for the pr. How can we fix this?

On our repository we've been using the format release-%major%.%minor%.%patch% for our releases. I tried to introduce your action so we could auto tag and release instead of our current manual process, but it doesn't work correctly with our format, eg always creates tag release-0.1.0 for a minor release, despite us already having many tags above that.

I had a look at the code and it seems this logic is missing here https://github.com/K-Phoen/semver-release-action/blob/master/internal/pkg/git/git.go but I'm not so familiar with Go myself to attempt a fix and PR myself.

Hi,

Really appreciate you making this Github action! I had a question regarding using custom tag. Is it possible to prefix the tag and then it auto increments?

For example: prod-v2.3 will then increment to prod-v2.4

Thank you.

Hello! Thanks for semver-release-action!
I try use your semver github action.
But i dont see example.
For example, how update patch version if commit have 'fix' string ?
For example, how update minor version if commit have 'feature' string ?

Currently if a PR merges that has no semver labels (patch, minor, major), the github action throws a 78 code and the github fails with message no valid semver label found

Am I missing a setting that allows the github action to actually skip instead of throwing a non-zero code?

Thank you in advance.

Have tried MULTIPLE times and submitted PR, no response. Tried email directly. No Response.

Best option is to fork and use your own.

Cheers.

You currently use go-github to handle your API calls, and it supports GitHub Enterprise Server.

Can you expose that support as configuration for this action, please?

I am trying to use this to get the GitHub Actions practice of tags for versioning, e.g. release vX.Y.Z but also create/update the vX.Y and vX tags. Right now when it tries to update the tag it returns the error: 422 Reference already exists. It also looks like it is not respecting the tag_format for the minor and major steps.

Example workflow:

steps:
- id: patch
  uses: k-phoen/[email protected] 
  with:
    release_branch: main
    release_strategy: release
    tag_format: v%major%.%minor%.%patch%
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

- id: minor
  uses: k-phoen/[email protected] 
  with:
    release_branch: main
    release_strategy: none
    tag_format: v%major%.%minor%
    tag: ${{ steps.patch.outputs.tag }}
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

- id: major
  uses: k-phoen/[email protected] 
  with:
    release_branch: main
    release_strategy: none
    tag_format: v%major%
    tag: ${{ steps.patch.outputs.tag }}
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Hello,

There is some "set-output" in the yml files, it is deprecated and will block pipelines since May.

https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/

Idea : actions/setup-go can be upgraded in v4

I have the use case where I want to do a "test" release.

I have release_strategy set to none but I still get.

::Executing bumper guard ::debug release_branch=master,github_event_path=/github/workflow/event.json
pull request not closed::debug ::Guard returned a neutral code, stopping the execution.

We are attempting to use this against a repo owned by an organisation, and receive the following errors:

::Executing bumper guard ::debug release_branch=master,github_event_path=/github/workflow/event.json
could not parse GitHub event: json: cannot unmarshal string into Go struct field Repository.repository.organization of type github.Organization::debug ::Executing bumper latest-tag github_repository=ChorusOne/anthem
could not create lightweight tag: POST https://api.github.com/repos/ChorusOne/anthem/git/refs: 422 refs/tags/invalid increment: could not parse GitHub event: json: cannot unmarshal string into Go struct field Repository.repository.organization of type github.Organization is not a valid ref name. []::set-output name=tag::invalid increment: could not parse GitHub event: json: cannot unmarshal string into Go struct field Repository.repository.organization of type github.Organization

Any ideas?

Hello! I really liked this solution on doing git tags & release based on labels of an PR.

Is there a possible way or example on how to bump up version on tags only but not execute release?

The action is getting failed when i set the event to pull_request and type as closed with an error 'Cannot read property 'message' of undefined' . But i can see it is running without error if i set the event to push and branch as master .But with the second case the version of the release is no following the label i set (major or minor) ,it is only releasing patch version with second case

@K-Phoen Hi, I'm wondering if you can do some update of the action - go.sum file?

Remediation
Upgrade gopkg.in/yaml.v2 to version 2.2.8 or later. For example:
require gopkg.in/yaml.v2 v2.2.8

CVE-2019-11254
Vulnerable versions: < 2.2.8
Patched version: 2.2.8
The Kubernetes API Server component in versions 1.1-1.14, and versions prior to 1.15.10, 1.16.7 and 1.17.3 allows an authorized user who sends malicious YAML payloads to cause the kube-apiserver to consume excessive CPU cycles while parsing YAML.

In our repository we currently want to have to semver releases for two different products the advance in different timelines. To do so, we want our semver incrementing separately based on the branch or on the tag_format as both of them are different in our case.
For example, say you have two products and a version to each of them: v0.0.1-a and v0.0.1-b and each of them is released when merging to different branches - A and B respectively. In the current settings, if we release a new patch of product A, the next release will be: v0.0.2-a. Then, if we wish to release a new patch for product B, it's version will be v0.0.3-b, our expected behavior is that it will be v0.0.2-b.

Let me know if you think this is an enhancement that can be useful for others as well.

Hi, I absolutely love this action. I think it's a fantastic way to declare versioning intent.

I use a private Gitea instance though, so I made some lazy/dirty changes to get it working.

If anyone is ever interested in abstracting the codebase a bit to accommodate both, hopefully some of that initial work can be lifted by checking out some of the necessary changes here using the Gitea SDK: https://github.com/3bbbeau/gitea-semver-release-action

(Note for any lurkers: I didn't publish the forked action as it wouldn't make much sense when both could be wrapped around a client interface in the upstream repo here, so you'd have to build it yourself).

Similarly to custom tags for the resulting release (#28), it'd be nice to be able to customise the patch/minor/major PR labels that trigger it, perhaps just with optional prefix, something like:

label_prefix: 'semver/'

(default '') so that it's triggered on e.g. semver/patch.

Having issues trying to run this workflow. Not sure if there is something I am missing

Most of the Go code is currently untested (and hard to test). It should be cleaned, refactored and tested.

Hello, is it possible with this Action to control version incrementing using PR label, so I can release with major/minor/patch update to release's tag?

I need it to automate release deploying with version changes (tenhobi/bachelors-thesis#8)

e.g. :

• release v0.1.1
  then PR w/ label "minor"
• release v0.2.0
  then PR w/ label "major"
• release v1.0.0

// Original question from actions/create-release#5 (comment)