Idea for enhancement: require confirmation for publish on non-master branch.

[possibilities]

On my projects I generally use a simple release script that saves me from making all kinds of stupid mistakes. One nice one is that it prompts me to confirm I want to publish outside of the master branch. Since I never want to do this it's a nice feature. Perhaps it makes sense in the context of lerna? I already accidentally published from a non-master branch so it would benefit me for sure. Thanks for considering, happy to generate a PR if desired!

[evocateur]

I am generally a favor of chaining such decisions in lifecycle scripts, but as we have the tools already to check the branch name and whatnot, this sounds reasonable.

Configuring this in lerna.json makes the most sense, but a flag for lerna publish would be necessary in any case to be consistent with the other configuration options. --allow-branch seems like a good name, it would require a string argument if the flag is passed, and that argument would be a glob (plain strings are globs too, e.g. --allow-branch master. It would implicitly default to ** (every branch), much like the --scope flag.

Here's how it would look in a lerna.json:

{
  "lerna": "2.1.2",
  "command": {
    "publish": {
      "allowBranch": "master"
    }
  },
  "version": "1.2.3"
}

[possibilities]

"Allow" doesn't seem semantically sound... Shouldn't it be phased E.g. "require", "demand" or "only"?

…

On Sep 4, 2017 4:25 PM, "Daniel Stockman" ***@***.***> wrote: I am generally a favor of chaining such decisions in lifecycle scripts, but as we have the tools already to check the branch name and whatnot, this sounds reasonable. Configuring this in lerna.json makes the most sense, but a flag for lerna publish would be necessary in any case to be consistent with the other configuration options. --allow-branch seems like a good name, it would require a string argument if the flag is passed, and that argument would be a glob (plain strings are globs too, e.g. --allow-branch master. It would implicitly default to ** (every branch), much like the --scope flag. Here's how it would look in a lerna.json: { "lerna": "2.1.2", "command": { "publish": { "allowBranch": "master" } }, "version": "1.2.3" } — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1007 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAer-ZQQ2-D1nXxVNnatzX58MXfMZkZpks5sfFylgaJpZM4PMHcB> .

[possibilities]

*phrased On Sep 4, 2017 5:01 PM, "Mike Bannister" <notimpossiblemike@gmail.com> wrote:

…

"Allow" doesn't seem semantically sound... Shouldn't it be phased E.g. "require", "demand" or "only"? On Sep 4, 2017 4:25 PM, "Daniel Stockman" ***@***.***> wrote: > I am generally a favor of chaining such decisions in lifecycle scripts, > but as we have the tools already to check the branch name and whatnot, this > sounds reasonable. > > Configuring this in lerna.json makes the most sense, but a flag for lerna > publish would be necessary in any case to be consistent with the other > configuration options. --allow-branch seems like a good name, it would > require a string argument if the flag is passed, and that argument would be > a glob (plain strings are globs too, e.g. --allow-branch master. It > would implicitly default to ** (every branch), much like the --scope > flag. > > Here's how it would look in a lerna.json: > > { > "lerna": "2.1.2", > "command": { > "publish": { > "allowBranch": "master" > } > }, > "version": "1.2.3" > } > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#1007 (comment)>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/AAer-ZQQ2-D1nXxVNnatzX58MXfMZkZpks5sfFylgaJpZM4PMHcB> > . >

[evocateur]

"Allow publish in branch <glob>" sounds meaningful to me. It is an optional whitelist, after all.

…

On Sep 4, 2017, at 14:01, Mike Bannister ***@***.***> wrote: *phrased On Sep 4, 2017 5:01 PM, "Mike Bannister" ***@***.***> wrote: > "Allow" doesn't seem semantically sound... Shouldn't it be phased E.g. > "require", "demand" or "only"? > > On Sep 4, 2017 4:25 PM, "Daniel Stockman" ***@***.***> > wrote: > >> I am generally a favor of chaining such decisions in lifecycle scripts, >> but as we have the tools already to check the branch name and whatnot, this >> sounds reasonable. >> >> Configuring this in lerna.json makes the most sense, but a flag for lerna >> publish would be necessary in any case to be consistent with the other >> configuration options. --allow-branch seems like a good name, it would >> require a string argument if the flag is passed, and that argument would be >> a glob (plain strings are globs too, e.g. --allow-branch master. It >> would implicitly default to ** (every branch), much like the --scope >> flag. >> >> Here's how it would look in a lerna.json: >> >> { >> "lerna": "2.1.2", >> "command": { >> "publish": { >> "allowBranch": "master" >> } >> }, >> "version": "1.2.3" >> } >> >> — >> You are receiving this because you authored the thread. >> Reply to this email directly, view it on GitHub >> <#1007 (comment)>, or mute >> the thread >> <https://github.com/notifications/unsubscribe-auth/AAer-ZQQ2-D1nXxVNnatzX58MXfMZkZpks5sfFylgaJpZM4PMHcB> >> . >> > — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[possibilities]

Ah OK, that does make some sense. I personally don't have a use case for a glob but yeah, I see where you're coming from.

[possibilities]

Ah, OK, I think what's awkward about it is that branch is singular so it doesn't evoke something that's globbable to me. Perhaps go plural and then maybe you don't even need a verb to qualify it "branches"?

[evocateur]

`--branches` is too ambiguous, seemingly implying that you'll publish a branch? I would expect this option to be 85% of the time a single string, like "master" or "live" or "next." However, I can see a strong case for allowing publishes from "release/*" or some other pattern chosen by other logic. I don't think plural is appropriate because the common use case will be a single branch name. A glob can match many things, true, but only a single glob is necessary.

…

On Sep 4, 2017, at 15:13, Mike Bannister ***@***.***> wrote: Ah, OK, I think what's awkward about it is that branch is singular so it doesn't evoke something that's globbable to me. Perhaps go plural and then maybe you don't even need a verb to qualify it "branches"? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[possibilities]

How bout --allow-branches ?

[evocateur]

I still don't think the plurality is necessary. Common case will be a plain string, and a glob is still singular.

…

On Sep 4, 2017, at 15:58, Mike Bannister ***@***.***> wrote: How bout --allow-branches ? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[possibilities]

Cool, thanks, I'll give it a shot...

[possibilities]

One thing I'm unsure of now is if it should fail or prompt when the current branch isn't allowed. Which would be least surprising?

[cezaraugusto]

I guess this can be closed given #1026 is merged already

[lock]

This thread has been automatically locked because there has not been any recent activity after it was closed. Please open a new issue for related bugs.