Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

auto version skipRelease behaviour #2372

Open
Yeti-or opened this issue Jun 20, 2023 · 6 comments
Open

auto version skipRelease behaviour #2372

Yeti-or opened this issue Jun 20, 2023 · 6 comments
Labels
bug Something isn't working

Comments

@Yeti-or
Copy link

Yeti-or commented Jun 20, 2023

I'm trying to release feature branch;

I have several pr-s in these branch, some of them are minors, some patches and some ci commits that should be skipped;
I merged itб but auto decided to skip my release

Please help me understand this behaviour

My labels:

prLabels [
  [ 'plasma-infra', 'skip-release' ],
  [ 'skip-release' ],
  [ 'skip-release' ],
  [ 'skip-release' ],
  [ 'skip-release' ],
  [ 'minor' ],
  [ 'minor' ],
  [ 'plasma-infra', 'Hotfix', 'skip-release' ],
  [ 'patch' ],
  [ 'plasma-infra', 'skip-release' ],
  [ 'skip-release' ],
  [ 'skip-release' ],
  [ 'plasma-infra', 'skip-release' ],
  [ 'skip-release' ],
  [ 'skip-release' ],
  [ 'skip-release' ],
  [ 'minor' ],
  [ 'minor' ],
  [ 'skip-release' ]
]

yes the last pr to feature branch is CI related, but I don't understand why we should skip release if only last label is 'skip-release' ?

the code I am asking about:

https://github.com/intuit/auto/blob/main/packages/core/src/semver.ts#L221-L223

  const skipRelease = onlyPublishWithReleaseLabel
    ? !lastMergedCommitLabels.some((label) => releaseLabels.includes(label))
    : lastMergedCommitLabels.some((label) => skipReleaseLabels.includes(label));

I don't understand why lastMergedCommit is more important then all other commits

Environment Information:

"auto" version: v10.36.6
"git"  version: v2.32.1 (Apple Git-133)
"node" version: v14.21.2

Project Information:

✔ Repository:      salute-developers/plasma
✔ Author Name:     Vasiliy Loginevskiy
✔ Author Email:    [email protected]
✖ Current Version: v
✔ Latest Release:  @salutejs/[email protected]

✖ Labels configured on GitHub project (Try running "auto create-labels")

GitHub Token Information:

✔ Token:            [Token starting with 3b3d]
✖ Repo Permission:  read
✔ User:            Eva
✔ API:
✔ Enabled Scopes:   gist, notifications, repo, user, workflow, write:discussion, write:packages
✔ Rate Limit:       4447/5000

Additional context

I use conventional-commits plugin to calc version bump

@Yeti-or Yeti-or added the bug Something isn't working label Jun 20, 2023
@hipstersmoothie
Copy link
Collaborator

I'm pretty sure the behavior is to skip the release if the head commit has skip-release on it. Without that a release should have gone out

@restfulhead
Copy link
Contributor

I got stumped by this as well. I'm trying to write a simple plugin that filters out commits. If no commits are in scope, the version command should return empty (SEMVER.noVersion).

This seems to be impossible: If I use omitCommit and all commits are filtered out, auto uses the default label (patch) instead of noVersion. So I thought ok then let me use parseCommit and slap a skip-release label on those commits instead. But then I run into the same problem as stated here, where the input like labels: [ [ 'skip-release' ], [ 'skip-release' ], [ 'release-patch' ], [] ], causes the SEMVER.noVersion instead of patch.

@hipstersmoothie
Copy link
Collaborator

I haven't been in the code here for awhile. but we may have a default label? I'd be open to a tiny pr to enable your use case

@restfulhead
Copy link
Contributor

@hipstersmoothie I've made my use case work in my filter-by-workspace-path plugin by overwriting the release.getSemverBump function and just returning SEMVER.noVersion if there are no commits. I don't think this really solves @Yeti-or's issue though. However, if you think it's a useful patch, I'd be happy to open a PR with this change.

@hipstersmoothie
Copy link
Collaborator

That's creative! Would have never thought to do that. Kinda cool you can completely control that

Will have to think about if the patch makes sense

@restfulhead
Copy link
Contributor

restfulhead commented Feb 23, 2024

That's creative! Would have never thought to do that. Kinda cool you can completely control that

Yeah, it does feel a bit hacky, but it works, hahah.

Btw, off-topic: I've just created an unrelated issue and PR for improving calcNextVersion, which I solved in a similar way. Would be nice if this could be merged, so that I could remove this workaround.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants