Adding a key for the pr build # #12
Conversation
… is a pull request. Allows to treat pr builds differently (for example, we might not want to deploy artifacts in a PR build)
| @@ -14,7 +18,11 @@ object TravisCiPlugin extends AutoPlugin { | |||
| override def trigger = allRequirements | |||
|
|
|||
| override def globalSettings = Seq( | |||
| isTravisBuild := sys.env.get("TRAVIS").isDefined) | |||
| isTravisBuild := sys.env.get("TRAVIS").isDefined, | |||
| prBuildNumber := Try { | |||
There was a problem hiding this comment.
Looks good. But I want to prefix the keys we introduce (it's a plugin best practice), so WDYT of travisPrNumber?
There was a problem hiding this comment.
Sounds good to me. Thanks for the quick feedback :)
… is a pull request. Allows to treat pr builds differently (for example, we might not want to deploy artifacts in a PR build)
|
@EmilDafinov, looks good. One more thing (sorry I should've mentioned this on my first feedback): could you document this in the README as well as in a release notes file under |
|
@dwijnand, I added a |
|
That's fine. I'm using here the same technique that we use in sbt. But in sbt we ended up quickly running into silly merge conflict warnings on release notes. So we use release notes directories for in-progress releases. Here things are more quiet, so we'll most likely not hit the issue. Thanks. LGTM. |
|
@dwijnand Quick follow up question, something that didn't occur to me when merging: We documented the new key in the 1.1.0 release notes, I'm assuming that is going to be the version of the plugin it will appear in. However, in the readme incorrectly indicates that it should be available in 1.0.0. Maybe it should not appear in the readme before 1.1.0 is released, what do you think? |
|
I think I could speak for a long time about this subject, from different angles and perspectives. I've seen many different solutions and I'm not sure which one I prefer. One way to avoid the whole problem is to just cut a release. Which thanks to using sbt-dynver and my build setup is quite simple. I'll cut 1.1.0. |
Adding a task key that allows to determine of the build is a pr build and what is its number. Allows PR builds to be handled differently.