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

Support multi-branch, multi-channel, LTS and pre-release workflows #563

Closed
pvdlg opened this issue Dec 15, 2017 · 74 comments

Comments

@pvdlg
Copy link
Member

commented Dec 15, 2017

This a proposal to support more complex release workflows in a fully automated way, including:

  • LTS branches and distribution channels
  • Future branches and distribution channels
  • Pre-releases

Please see semantic-release/evolution#1 for the proposed list of workflows to be supported by semantic-release.

semantic-release modifications

  • Add the new branches options
  • Normalize each branch configuration based on naming convention
  • Validate the branches configuration
  • Re-purpose the branch options as the current branch on which semantic-release is running
  • Verify that only allowed release are made
    • On LTS branches verify it's in range
    • In default and future branches make sure that releasing will comply with the type of the following non pre-release future branch
  • When no version has to be released, check if we are in a merge situation (the commit associated with the last release is present in following branch and it is not a pre-release branch)
    • If yes, make a release in order for the publish plugins to update the channel
  • Determine if the branch is a pre-release one, and if it is increment the version accordingly
  • Pass the channel on which to release nextRelease to the publish plugins
  • Move the git tag creation to the core

publish plugins modifications

  • If release already exists, make it available on nextRelease.channel (in case of github, remove the prerelease flag if the target channel is the default one)
  • For the npm plugin, always publish on the dist-tag passed in nextRelease.channel or latest if nextRelease.channel is not set
  • For the github plugin, set prerelease flag if the current branch is a future or prerelease
  • Remove the tag creation from the publish plugins

Deprecate getLastRelease plugins

  • Move the getLastRelease logic of the git plugin into the core

This is fairly broad and complex subject, so I'd love to have feedback from the community, in particular:

  • Is there a type of workflow that wouldn't be supported with this new feature?
  • Is there some potential inconsistencies that are not covered? (i.e. would it be possible to create a release that shouldn't happen, or create an incoherent situation).
  • Would this feature create issue with a specific publishing platform? Or should this feature be adapted to support a specific platform via plugin?
@gr2m

This comment has been minimized.

Copy link
Contributor

commented Dec 21, 2017

Wow, you put lots of thoughts into this. I love the idea of "Branches naming convention"!

Here some notes from my first review. I’ll give it some more thoughts with suggestions on how to move forward :)

Distribution channels to make unstable version available to early adopters. Usually named next or unstable.

I’ve never seen a dist tag called unstable. Maybe just leave it at "Usually named next?

A software meant to be used by final users

end users

"channel"

I wonder if instead of "channel" we should call it "npm-dist-tag", to make it super clear what it is?

push to 1.x.x or 2.x.x branches

I think it’s more common to call them 1.x and 2.x branches

(Pre-releases) "branches": ["master", "4.0.0-beta", "5.0.0-alpha"]

When I push to the 4.0.0-beta branch and it releases a 4.0.0-beta version to npm, what happens with the GitHub release notes? I think there would be a conflict with the branch 4.0.0-beta as the release would need a git tag with the same name, I think that is not possible, but I haven’t checked it.

I’m also not sure if releasing these pre versions to @latest is the right approach? Because if I do npm install my-pkg I get my-pakg@4.0.0-beta if it’s released to latest, I’m not sure if that is the intent? Shouldn’t these rathe be relesed to @beta release channel instead?

@pvdlg

This comment has been minimized.

Copy link
Member Author

commented Dec 21, 2017

I’ve never seen a dist tag called unstable. Maybe just leave it at "Usually named next?

I think unstable is kind of the naming convention in the Linux world, mostly because Debian name future releases like that. But mentioning only next probably make more sense.

I wonder if instead of "channel" we should call it "npm-dist-tag", to make it super clear what it is?

The objective was to use a generic name that is not attached to a specific package manager like npm, as we want to support any type of release target, not only npm. Channel is the generic term used by Google for this type of distribution: https://support.google.com/chromebook/answer/1086915?hl=en

I think it’s more common to call them 1.x and 2.x branches

Both works, as long it's a valid semver range it will be detected as a LTS branch. I'll make it more clear in the doc.

When I push to the 4.0.0-beta branch and it releases a 4.0.0-beta version to npm, what happens with the GitHub release notes? I think there would be a conflict with the branch 4.0.0-beta as the release would need a git tag with the same name, I think that is not possible, but I haven’t checked it.

The tag will be 4.0.0-beta.X where X is the iteration: 4.0.0-beta.0, 4.0.0-beta.1, 4.0.0-beta.2 etc... But that's a good feedback, I'll make sure we'll never end up with tag/branch conflict.

I’m also not sure if releasing these pre versions to @latest is the right approach? Because if I do npm install my-pkg I get my-pakg@4.0.0-beta if it’s released to latest, I’m not sure if that is the intent? Shouldn’t these rathe be relesed to @beta release channel instead?

As far as I understand if you do npm install my-pkg you will not get my-pakg@4.0.0-beta, you will get the highest non pre-release version available on @latest. I'll test to make sure.

@pvdlg pvdlg self-assigned this Dec 21, 2017

@felixfbecker

This comment has been minimized.

Copy link
Contributor

commented Dec 22, 2017

As far as I understand if you do npm install my-pkg you will not get my-pakg@4.0.0-beta, you will get the highest non pre-release version available on @latest. I'll test to make sure.

Afaik npm install my-pkg will always get you latest, and if that was set to a prerelease, then you will get a prerelease. I already opened many issues because package maintainers forgot to publish with --dist-tag=next and accidentally tagged latest to a prerelease. But maybe npm changed it?

@schickling

This comment has been minimized.

Copy link

commented Jan 2, 2018

This is highly appreciated. Our current workflow is:

  1. Create a new branch (e.g. dev)

  2. Assuming you're on the dev branch, you need to add the following to your package.json to publish using the next NPM tag:

  "release": {
    "branch": "dev"
  },
  "publishConfig": {
    "tag": "next"
  }
  1. Before merging back to master (typically via PR) remove everything from (2) again.

@pvdlg do you (or someone else) have suggestions on how to improve this workflow until this issue has been implemented and released?

@pvdlg

This comment has been minimized.

Copy link
Member Author

commented Jan 2, 2018

@schickling thanks for the feedback!

Actually I don't really understand how to workflow you are describing could currently works. Let's say you have a version 1.0.0 released on npm which correspond to the sate of the master branch. The 1.0.0 has been made available on the @latest dist-tag.
Then you create a dev branch (step 1), set the config (step 2) and push a feature commit on it. That will trigger a 1.1.0 release that will be available only on the @next dist-tag. Then you change the config and merge to master (step 3). That will trigger a release process from master that will attempt to release 1.1.0 and make it available on @latest, but that would fail as 1.1.0 already exists.

Can you clarify how you make that works? Is what you are trying to achieve is to make the code that only on dev available to only early adopters?

@schickling

This comment has been minimized.

Copy link

commented Jan 2, 2018

Ideally we'd be able to "promote" released versions by assigning the latest (or another) tag.
So far we've been releasing versions like 1.1.0-beta.1, 1.1.0-beta.2 etc. How would we do something like this using semantic-release?

@pvdlg

This comment has been minimized.

Copy link
Member Author

commented Jan 2, 2018

Ah ok, I think I understand better now. The workflow is:

  • push on dev => release a beta version available only @next
  • push on master (by merging from dev) => release a normal version available on @latest dist-tag

That's not currently possible as we don't have a way to make pre-release (i.e. 1.1.0-beta.1) in semantic-release currently. The new feature would allow to do that with a pre-release branch.

What you can do now is something similar to what we do in the semantic-release repo:

  • Only one branch master (named caribou for this particular repo)
  • Push to master => release a normal version available on @next dist-tag
  • When we want to promote a release (make it available for everyone) we make it available on @latest with npm dist-tag add semantic-release@<version to promote> latest

@pvdlg pvdlg added plugin:gitlab and removed plugin:travis labels Jan 6, 2018

@priley86

This comment has been minimized.

Copy link

commented Jan 8, 2018

off topic guys... please do a better job of announcing these breaking changes in a README or something... i love this tool and i rarely complain about other's open source work, but this is quickly becoming a mysterious library that I'm somewhat afraid of upgrading. Please do your best to ensure error messages are helpful for the end user.

For anyone else upgrading from an earlier version and searching these github issues, you may receive an error like this:

> semantic-release pre && npm publish && semantic-release post
  Usage: semantic-release [options]
  Run automated package publishing
  Options:
    -b, --branch <branch>                Branch to release from
    -r, --repositoryUrl <repositoryUrl>  Git repository URL
    --verify-conditions <paths>          Comma separated list of paths or packages name for the verifyConditions plugin(s)
    --get-last-release <path>            Path or package name for the getLastRelease plugin
    --analyze-commits <path>             Path or package name for the analyzeCommits plugin
    --verify-release <paths>             Comma separated list of paths or packages name for the verifyRelease plugin(s)
    --generate-notes <path>              Path or package name for the generateNotes plugin
    --publish <paths>                    Comma separated list of paths or packages name for the publish plugin(s)
    --debug                              Output debugging information
    -d, --dry-run                        Dry-run mode, skipping verifyConditions, publishing and release, printing next version and release notes
    -h, --help                           output usage information
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! patternfly-react@0.0.0-semantically-released semantic-release: `semantic-release pre && npm publish && semantic-release post`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the patternfly-react@0.0.0-semantically-released semantic-release script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! A complete log of this run can be found in:
npm ERR!     /home/travis/.npm/_logs/2018-01-08T19_59_14_238Z-debug.log

This likely means you missed @pvdlg 's comment here with the suggested fix:
#411 (comment)

With no errors/readme updates, i'm just really hoping someone else finds this issue since the original is now locked!

@gr2m

This comment has been minimized.

Copy link
Contributor

commented Dec 18, 2018

I just set this up for nock. I successfully released a beta pre-release https://github.com/nock/nock/releases/tag/v11.0.0-beta.1%40beta, but after I merged more pull requests into "beta" the publish failed with the error

semantic-release cannot push the version tag to the branch undefined on remote Git repository with URL https://[secure]@github.com/nock/nock.git.

nock/nock#1304. build error on travis

I think the problem might have been that I merged multiple pull requests into quick succession, before the current build could finish. The last build was able to finish and did not have the problem

@pvdlg

This comment has been minimized.

Copy link
Member Author

commented Dec 18, 2018

The undefined in the message should be solved in #1043.

However you should have had the message The local branch beta is behind the remote one, therefore a new version won't be published. and the build should have not failed. I don't understand why it didn't work...

That would be helpful to have debug messages. I think that would be a great idea to always enable --debug or DEBUG=semantic-release:* for anyone testing the beta.

@SimonFinney

This comment has been minimized.

Copy link

commented Dec 19, 2018

I can confirm this is working for me with the following configuration -

{
  branches: [
    'master',
    {
      name: 'dev',
      prerelease: 'prerelease',
      channel: 'next',
    },
  ]
}

Thanks @pvdlg!

@gr2m

This comment has been minimized.

Copy link
Contributor

commented Dec 19, 2018

When the git push --dry-run https://[secure]@github.com/nock/nock.git HEAD:beta command fails due to (non-fast-forward) error, it creates an issues saying that the problem is "The push permission to the Git repository is required."

nock/nock#1327

nock is using 16.0.0-beta.13

@pvdlg

This comment has been minimized.

Copy link
Member Author

commented Dec 19, 2018

It's the same issue as #563 (comment). When this error occurs we call isBranchUpToDate to check if it's due the local branch being behind or to another problem.
The error ! [rejected] HEAD -> beta (non-fast-forward) indicate the local branch is behind the remote one, so isBranchUpToDate should return false and semantic-release should exit with false. However it seems isBranchUpToDate returns true in that case but I don't know why.

Having the debug logs would be helpful.

@renemr86

This comment has been minimized.

Copy link

commented Dec 27, 2018

First of all, awesome tool! We've been using semantic-release for some time on Java projects with Gradle and CircleCI and it has been great!

Now we decided to move on to the beta version and publish releases on multiple branches. Until now, everything is working like a charm.

Thanks

@gr2m

This comment has been minimized.

Copy link
Contributor

commented Jan 6, 2019

I had another of the ! [rejected] HEAD -> beta (non-fast-forward) errors. We are using the latest beta of semantic-release. I’m now fairly sure that it’s a timing problem. I merged several pull requests in quick succession, I assume that while the release build started, I merged another pr, hence the non-fast-forward error.

I wonder if we could add an error handler for that error to check if the last remote commit changed and if it did, log a more helpful message and then exit without an error, as we can assume that the new commit triggered another build?

https://travis-ci.org/nock/nock/jobs/475937483#L505

[10:13:48 AM] [semantic-release] › ✔  Run automated release from branch beta
2019-01-06T10:13:48.430Z semantic-release:git Error: Command failed: git push --dry-run https://github.com/nock/nock.git HEAD:beta
remote: Invalid username or password.
fatal: Authentication failed for 'https://github.com/nock/nock.git/'
    at makeError (/home/travis/build/nock/nock/node_modules/semantic-release/node_modules/execa/index.js:174:9)
    at Promise.all.then.arr (/home/travis/build/nock/nock/node_modules/semantic-release/node_modules/execa/index.js:278:16)
    at process._tickCallback (internal/process/next_tick.js:68:7)
2019-01-06T10:13:48.836Z semantic-release:git Error: Command failed: git push --dry-run https://[secure]@github.com/nock/nock.git HEAD:beta
To https://github.com/nock/nock.git
 ! [rejected]        HEAD -> beta (non-fast-forward)
@renemr86

This comment has been minimized.

Copy link

commented Jan 7, 2019

Hello

I'm trying to replicate the example Working on a third future release, however when I commit on alpha branch the semantic-release set the next release version with the next beta version (2.0.0-beta.3) instead of the next alpha version (3.0.0-alpha.1).

Example repository:
https://github.com/renemr86/semantic-release-test

.releaserc:

tagFormat: ${version}

branches:
  - master
  - name: next
    prerelease: 'rc'
  - name: beta
    prerelease: 'beta'
  - name: alpha
    prerelease: 'alpha'

verifyConditions:
  - "@semantic-release/git"
generateNotes: []
prepare: []
publish: []
success: []
fail: []
$ npx semantic-release --no-ci
[12:55:00 PM] [semantic-release] › ℹ  Running semantic-release version 16.0.0-beta.15
[12:55:00 PM] [semantic-release] › ✔  Loaded plugin "verifyConditions" from "@semantic-release/git"
[12:55:00 PM] [semantic-release] › ✔  Loaded plugin "analyzeCommits" from "@semantic-release/commit-analyzer"
[12:55:00 PM] [semantic-release] › ✔  Loaded plugin "addChannel" from "@semantic-release/npm"
[12:55:00 PM] [semantic-release] › ✔  Loaded plugin "addChannel" from "@semantic-release/github"
[12:55:15 PM] [semantic-release] › ✔  Run automated release from branch alpha
[12:55:21 PM] [semantic-release] › ✔  Allowed to push to the Git repository
[12:55:21 PM] [semantic-release] › ℹ  Start step "verifyConditions" of plugin "@semantic-release/git"
[12:55:21 PM] [semantic-release] › ✔  Completed step "verifyConditions" of plugin "@semantic-release/git"
[12:55:21 PM] [semantic-release] › ℹ  Found git tag 2.0.0-beta.2@beta associated with version 2.0.0-beta.2 on branch alpha
[12:55:21 PM] [semantic-release] › ℹ  Found 1 commits since last release
[12:55:21 PM] [semantic-release] › ℹ  Start step "analyzeCommits" of plugin "@semantic-release/commit-analyzer"
[12:55:21 PM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  Analyzing commit: feat: first feature of other release

BREAKING CHANGE: it breaks something
[12:55:21 PM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  The release type for the commit is major
[12:55:21 PM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  Analysis of 1 commits complete: major release
[12:55:21 PM] [semantic-release] › ✔  Completed step "analyzeCommits" of plugin "@semantic-release/commit-analyzer"
[12:55:21 PM] [semantic-release] › ℹ  The next release version is 2.0.0-beta.3
[12:55:24 PM] [semantic-release] › ✔  Created tag 2.0.0-beta.3@alpha
[12:55:24 PM] [semantic-release] › ✔  Published release 2.0.0-beta.3
$ git log --graph --oneline --all --decorate --date-order
* 461efd6 (HEAD -> alpha, tag: 2.0.0-beta.3@alpha, origin/alpha, bitbucket/alpha) feat: first feature of other release
| * 6bca0e4 (tag: 1.0.1, origin/master, bitbucket/master, master) fix: a fix
* | bbbaf5f (tag: 2.0.0-beta.2@beta, origin/beta, bitbucket/beta, beta) feat: second feature
* | 4409cd5 (tag: 2.0.0-beta.1@beta) feat: first feature
|/  
* cc1021a (tag: 1.0.0) feat: initial commit

@travi

This comment has been minimized.

Copy link
Contributor

commented Jan 22, 2019

i just published a couple of beta versions. first a fix, then a BREAKING CHANGE. the first published a patch pre-release, as expected. for the second, i expected the pre-release to be bumped to a major, but a second pre-release of the patch was published.

is this the expected incrementing behavior? from the log, it appears that it was correctly detected as a major change.

@bddckr

This comment has been minimized.

Copy link

commented Jan 22, 2019

AFAIK this is expected - a pre-release always seems to advance by just updating the pre-release number, the "actual version" number always stays the same.

I tried finding an explanation of this in the documentation but I don't think it clearly states this behavior. In case it really doesn't (I may have missed it) it should not just explicitly note the behavior for breaking changes, but instead note that this is true for any form of commit that would normally change the version.

@pvdlg

This comment has been minimized.

Copy link
Member Author

commented Jan 22, 2019

Yes that's the intended behavior. That allows you when working on a pre-release to make as many fix, feature or breaking change without incrementing the version.
Once you merge the pre-release branch to a regular branch then normal version will be released.

@travi

This comment has been minimized.

Copy link
Contributor

commented Jan 22, 2019

gotcha. im familiar with the behavior once things get merged, but i guess i had an incorrect assumption about the pre-release versioning. i assumed it would increment the patch pre-release until a more impactful (minor/major) change was added and then would publish a minor/major pre-release instead. fair enough if thats not the expectation

@felixfbecker

This comment has been minimized.

Copy link
Contributor

commented Jan 22, 2019

I agree that it's unintuitive - if we know that the next non-pre release will have a breaking change, shouldn't the prerelease be for the next major version? I.e. if at least one breaking change is detected on a prerelease branch, the major should be bumped (once). More breaking changes would then only bump the prerelease number.

@travi

This comment has been minimized.

Copy link
Contributor

commented Jan 24, 2019

i've been thinking about this some more and thought it could be helpful to at least share a bit more about where my assumptions/hopes came from. Not necessarily trying to convince anyone about a change, but at least maybe adding a few more thoughts around the topic:

a pre-release always seems to advance by just updating the pre-release number, the "actual version" number always stays the same

i mostly agree with this and have followed that mentality when manually publishing pre-releases. however, i see two problems that i've either run into in that approach that i think could be different when using semantic-release.

manually, i could think through the changes that i expect to make and do the semantic math myself to set the initial "version" to match the most impactful change i expect to make. if i know i'll be making a breaking change, ill make the inital pre-release suggest that. with semantic-release, it depends on which change is made first. in my case above, i made a commit that triggered only a patch before making a commit that would normally trigger a major. admittedly, this time that order was to test out what semantic-release would do, but i've followed that approach legitimately many times in the past (and was why i was curious).

the second piece is that i could simply be wrong. i may not realize that a series of pre-releases that i expected to only add new functionality would end up forcing me to break a public api. in normal use of semantic-release, i purposely dont fret about these types of things because i know it will handle translation of my changes into the proper semantic version.

in addition, theres always the possibility that master releases an independent change that increments the version published to latest beyond what the pre-release is referencing. that ends up being downright confusing for the next pre-release, so the ideal behavior, in my mind, would be that the pre-release version would account for that as well after merging master into the pre-release branch.

while i agree that the version part of the pre-release tends to be somewhat meaningless, i think semantic-release has enough information available to potentially make it more meaningful. as a consumer, it is certainly helpful to understand, from the semantic version, what the impact of the change is. when pulling in a pre-release, that information is a bit different, since it is the impact relative to what has been deployed as latest. however, without the updates that i'm referring to, its more relative to what was deployed as latest when the first pre-release was cut and only suggests the impact of the first change(s) that resulted in the publish of that first pre-release.

as i said, i can see both sides and am not necessarily trying to convince that there should be a change, but hopefully these details help articulate what my assumptions were since i think there is a potential opportunity for semantic-release to provide further semantic value for pre-releases.

@renemr86

This comment has been minimized.

Copy link

commented Jan 31, 2019

I'm using semantic-release on a pre-release branch (beta). When I commit a break change, the semantic-release correctly indicates that a new major version will be generated, however instead of increasing the major version (4.0.0-beta.1), it keeps the current version (3.38.0) and only increases the pre-release version (3.38.0-beta.15 to 3.38.0-beta.16).

npx semantic-release
[3:27:51 PM] [semantic-release] › ℹ  Running semantic-release version 16.0.0-beta.18
[3:27:51 PM] [semantic-release] › ✔  Loaded plugin "verifyConditions" from "@semantic-release/git"
[3:27:51 PM] [semantic-release] › ✔  Loaded plugin "analyzeCommits" from "@semantic-release/commit-analyzer"
[3:27:51 PM] [semantic-release] › ✔  Loaded plugin "prepare" from "@semantic-release/exec"
[3:27:51 PM] [semantic-release] › ✔  Loaded plugin "publish" from "@semantic-release/exec"
[3:27:51 PM] [semantic-release] › ✔  Loaded plugin "publish" from "@semantic-release/exec"
[3:27:51 PM] [semantic-release] › ✔  Loaded plugin "addChannel" from "@semantic-release/npm"
[3:27:51 PM] [semantic-release] › ✔  Loaded plugin "addChannel" from "@semantic-release/github"
[3:27:51 PM] [semantic-release] › ⚠  This run was not triggered in a known CI environment, running in dry-run mode.
[3:28:11 PM] [semantic-release] › ⚠  Run automated release from branch beta in dry-run mode
[3:28:16 PM] [semantic-release] › ✔  Allowed to push to the Git repository
[3:28:16 PM] [semantic-release] › ℹ  Start step "verifyConditions" of plugin "@semantic-release/git"
[3:28:16 PM] [semantic-release] › ✔  Completed step "verifyConditions" of plugin "@semantic-release/git"
[3:28:16 PM] [semantic-release] › ℹ  Found git tag 3.38.0-beta.15@beta associated with version 3.38.0-beta.15 on branch beta
[3:28:16 PM] [semantic-release] › ℹ  Found 2 commits since last release
[3:28:16 PM] [semantic-release] › ℹ  Start step "analyzeCommits" of plugin "@semantic-release/commit-analyzer"
[3:28:16 PM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  Analyzing commit: ci(circle/semantic-release): upgrade semantic-release
[3:28:16 PM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  The commit should not trigger a release
[3:28:16 PM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  Analyzing commit: feat(something): description

BREAKING CHANGE: description
[3:28:16 PM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  The release type for the commit is major
[3:28:16 PM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  Analysis of 2 commits complete: major release
[3:28:16 PM] [semantic-release] › ✔  Completed step "analyzeCommits" of plugin "@semantic-release/commit-analyzer"
[3:28:16 PM] [semantic-release] › ℹ  The next release version is 3.38.0-beta.16
[3:28:16 PM] [semantic-release] › ⚠  Skip step "prepare" of plugin "@semantic-release/exec" in dry-run mode
[3:28:16 PM] [semantic-release] › ⚠  Skip 3.38.0-beta.16@beta tag creation in dry-run mode
[3:28:16 PM] [semantic-release] › ⚠  Skip step "publish" of plugin "@semantic-release/exec" in dry-run mode
[3:28:16 PM] [semantic-release] › ⚠  Skip step "publish" of plugin "@semantic-release/exec" in dry-run mode
[3:28:16 PM] [semantic-release] › ✔  Published release 3.38.0-beta.16
[3:28:16 PM] [semantic-release] › ℹ  Release note for version 3.38.0-beta.16:
@gr2m

This comment has been minimized.

Copy link
Contributor

commented Mar 3, 2019

I just tried to release a 7.x release for Probot. I think everything was setup created, the 7.x branch was created based on the last 7x release tag (v7.5). But instead of creating 7.5.1, it created a tag v7.0.0@7.x and I’m not sure what exactly it did on npm?

Here are the full logs: https://travis-ci.org/probot/probot/jobs/501226804

Update 1

Oh it actually got rogue and after "releasing" 7.0.0, it continued with all the other existing tags :( https://travis-ci.org/probot/probot/jobs/501226804#L595 we canceled it eventually after it created v7.0.0@7.x, v7.1.0@7.x, and v7.1.1@7.x

Update 2

I manually create the tag v7.5.0@7.x and updated the @release-7.x npm dist tag to point to 7.5.0, then pushed another fix commit, but it continued with creating where it left off and created v7.2.0@7.x so I canceled it again: https://travis-ci.org/probot/probot/jobs/501234571#L507

Update 3

It now worked as expected, after creating all in-between branches: https://travis-ci.org/probot/probot/jobs/501237021

Turns out, @latest dist tag points to 7.5.0, we should have merged into master in the first place because v8 was only released on @next so far.

But still the above behavior looks like a bug

@gr2m

This comment was marked as resolved.

Copy link
Contributor

commented Mar 3, 2019

Oh it actually got rogue and after "releasing" 7.0.0, it continued with all the other existing tags :( https://travis-ci.org/probot/probot/jobs/501226804#L595 we canceled it eventually

@grv87 grv87 referenced this issue Mar 31, 2019
4 of 4 tasks complete
@rodoabad

This comment has been minimized.

Copy link

commented May 14, 2019

How do you use a pre-release version? npm i semantic-release@next?

EDIT:

Looks like...

dist-tags:
alpaca: 3.4.1         badger: 4.3.5         beta: 16.0.0-beta.19  latest: 15.13.12      next: 15.13.14        

npm i semantic-release@beta

@sanderaernouts

This comment has been minimized.

Copy link

commented Jun 8, 2019

@pvdlg I'm trying this with 16.0.0-beta.22 but I'm getting this message when running it on branch alpha:

[10:32:36 PM] [semantic-release] » i  This test run was triggered on the branch alpha, while semantic-release is configured to only publish from master, therefore a new version won’t be published.
@austince austince referenced this issue Jun 18, 2019
2 of 2 tasks complete
@haldunanil

This comment has been minimized.

Copy link

commented Jun 27, 2019

@pvdlg does the pre-release workflow support blobs in branch names? for example, I want to have a branch named release/v2.0.0, where the vX.0.0 changes as I go up the branch names and each iteration is deleted after being merged into master. Can I configure semantic-release to recognize branch names by using a blob like release/* and then have all of them tagged with beta?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.