Make commit & tag messages build-level settings#205
Conversation
|
The failing Travis test are due to the upgrade to 0.13.15. I've fixed them in my recent SBT 1.0 PR. If you rebase this PR onto the current master, they should disappear. |
|
Oh, and by the way, I fully support this PR and the use of present tense in particular. I agree that this should be in a version 2.x though. |
Aha, thank you for the heads up! I'd had no chance to come back and investigate yet since the build ran but that will make it much easier to dig back in. I'll try to update the PR soon and perhaps also carve out the time to more thoroughly consider what else can/should sensibly be |
|
@xuwei-k Any chance of any movement on this? It seems the current situation also makes it impossible to override these settings with a "house rules" plugin, i.e. a company-local plugin we use across our code bases to supply sensible defaults to the other plugins we're using. (I'll be happy to take over the PR by resolving conflicts or whatever, but I won't bother if it's just going to linger...) EDIT: ... just add, I'd also be happy if the message could just be changed to present tense -- it's such an eyesore to have the automatic commit messages be the "bad" ones... |
I end up doing this in every project where I use sbt-release:
Then I need to add
settings(releaseSettings)to every applicable module of multi-project builds or include them in some common settings collection. That has become tedious, so here I am. I would like for these to be able to delegate toThisBuildso I can just do this once, perhaps even in an umbrella plugin for team standards:Could more settings sensibly move to
buildSettings? Quite possibly, I didn't think about it very hard, these are ones that initially were of interest to me but I'm open to suggestions.Also the scripted suite seems to have some issue in my environment, if Travis fails for this PR or you'd like a new test for this change I'll dig further into what's not kosher on my machine. Apologies for being in a bit of a rush.
(By the way, if you're open to changing the default messages to present tense, imperative mood as many style guides call for in accordance with the Git project's own convention, I'd be happy to change it. But I suspect people could have automation scripting in their pipeline reliant on the existing default messages, so it might be considered a compatibility breakage).