在线时间:8:00-16:00
迪恩网络APP
随时随地掌握行业动态
扫描二维码
关注迪恩网络微信公众号
开源软件名称:sbt/sbt-release开源软件地址:https://github.com/sbt/sbt-release开源编程语言:Scala 100.0%开源软件介绍:sbt-releaseThis sbt plugin provides a customizable release process that you can add to your project. Notice: This README contains information for the latest release. Please refer to the documents for a specific version by looking up the respective tag. Requirements
UsageAdd the following lines to addSbtPlugin("com.github.sbt" % "sbt-release" % "1.1.0") version.sbtSince the build definition is actual Scala code, it's not as straight forward to change something in the middle of it as it is with an XML definition. For this reason, sbt-release won't ever touch your build definition files, but instead writes the new release or development version to a file defined by the setting By default the version is set on the build level (using Release ProcessThe default release process consists of the following tasks:
In case of a failure of a task, the release process is aborted. Non-interactive releaseYou can run a non-interactive release by providing the argument For all interactions, the following default value will be chosen:
Set release version and next version as command argumentsYou can set the release version using the argument Example:
Skipping testsFor that emergency release at 2am on a Sunday, you can optionally avoid running any tests by providing the Cross building during a releaseSince version 0.7, sbt-release comes with built-in support for cross building and cross publishing. A cross release can be triggered in two ways:
Combining both ways of steering a cross release, it is possible to generally disable automatic detection of cross release by using Of the predefined release steps, the A cross release behaves analogous to using the
In the section Customizing the release process we take a look at how to define a Convenient versioningAs of version 0.8, sbt-release comes with four strategies for computing the next snapshot version via the
Example:
Custom versioningsbt-release comes with two settings for deriving the release version and the next development version from a given version. These derived versions are used for the suggestions/defaults in the prompt and for non-interactive releases. Let's take a look at the types: val releaseVersion : SettingKey[String => String]
val releaseNextVersion : SettingKey[String => String] The default settings make use of the helper class // strip the qualifier off the input version, eg. 1.2.1-SNAPSHOT -> 1.2.1
releaseVersion := { ver => Version(ver).map(_.withoutQualifier.string).getOrElse(versionFormatError(ver)) }
// bump the version and append '-SNAPSHOT', eg. 1.2.1 -> 1.3.0-SNAPSHOT
releaseNextVersion := {
ver => Version(ver).map(_.bump(releaseVersionBump.value).asSnapshot.string).getOrElse(versionFormatError(ver))
}, If you want to customize the versioning, keep the following in mind:
Custom VCS messagessbt-release has built in support to commit/push to Git, Mercurial and Subversion repositories. The messages for the tag and the commits can be customized to your needs with these settings: val releaseTagComment : TaskKey[String]
val releaseCommitMessage : TaskKey[String]
val releaseNextCommitMessage : TaskKey[String]
// defaults
releaseTagComment := s"Releasing ${(ThisBuild / version).value}",
releaseCommitMessage := s"Setting version to ${(ThisBuild / version).value}",
releaseNextCommitMessage := s"Setting version to ${(ThisBuild / version).value}", Publishing signed releasesSBT is able to publish signed releases using the sbt-pgp plugin. After setting that up for your project, you can then tell sbt-release to use it by setting the releasePublishArtifactsAction := PgpKeys.publishSigned.value Customizing the release processNot all releases are created equalThe release process can be customized to the project's needs.
The release process is defined by State transformation functions ( case class ReleaseStep (
action: State => State,
check: State => State = identity,
enableCrossBuild: Boolean = false
) The function The sequence of The state transformations functions used in sbt-release are the same as the action/body part of a no-argument command. You can read more about building commands in the sbt website. Release StepsThere are basically 2 ways to creating a new Defining your own release stepsYou can define your own state tansformation functions, just like sbt-release does, for example: val checkOrganization = ReleaseStep(action = st => {
// extract the build state
val extracted = Project.extract(st)
// retrieve the value of the organization SettingKey
val org = extracted.get(Keys.organization)
if (org.startsWith("com.acme"))
sys.error("Hey, no need to release a toy project!")
st
}) We will later see how to let this release step participate in the release process. Reusing already defined tasksSometimes you just want to run an existing task or command. This is especially useful if the task raises an error in case something went wrong and therefore interrupts the release process. sbt-release comes with a few convenience functions for converting tasks and commands to release steps:
For example: releaseProcess := Seq[ReleaseStep](
releaseStepInputTask(testOnly, " com.example.MyTest"),
releaseStepInputTask(scripted),
releaseStepTask(publish in subproject),
releaseStepCommand("sonatypeRelease")
) I highly recommend to make yourself familiar with the State API before you continue your journey to a fully customized release process. Can we finally customize that release process, please?Yes, and as a start, let's take a look at the default definition of The default release processimport ReleaseTransformations._
// ...
releaseProcess := Seq[ReleaseStep](
checkSnapshotDependencies, // : ReleaseStep
inquireVersions, // : ReleaseStep
runClean, // : ReleaseStep
runTest, // : ReleaseStep
setReleaseVersion, // : ReleaseStep
commitReleaseVersion, // : ReleaseStep, performs the initial git checks
tagRelease, // : ReleaseStep
publishArtifacts, // : ReleaseStep, checks whether `publishTo` is properly set up
setNextVersion, // : ReleaseStep
commitNextVersion, // : ReleaseStep
pushChanges // : ReleaseStep, also checks that an upstream branch is properly configured
) The names of the individual steps of the release process are pretty much self-describing.
Notice how we can just reuse the Note, the No Git, and no toy projects!Let's modify the previous release process and remove the Git related steps, who uses that anyway. import ReleaseTransformations._
// ...
ReleaseKeys.releaseProcess := Seq[ReleaseStep](
checkOrganization, // Look Ma', my own release step!
checkSnapshotDependencies,
inquireVersions,
runTest,
setReleaseVersion,
publishArtifacts,
setNextVersion
) Overall, the process stayed pretty much the same:
Release notes anyone?Now let's also add steps for posterous-sbt: import posterous.Publish._
import ReleaseTransformations._
// ...
val publishReleaseNotes = (ref: ProjectRef) => ReleaseStep(
check = releaseStepTaskAggregated(check in Posterous in ref), // upfront check
action = releaseStepTaskAggregated(publish in Posterous in ref) // publish release notes
)
// ...
ReleaseKeys.releaseProcess <<= thisProjectRef apply { ref =>
import ReleaseStateTransformations._
Seq[ReleaseStep](
checkOrganization,
checkSnapshotDependencies,
inquireVersions,
runTest,
setReleaseVersion,
publishArtifacts,
publishReleaseNotes(ref) // we need to forward `thisProjectRef` for proper scoping of the underlying tasks
setNextVersion
)
} The CreditsThank you, Jason and Mark, for your feedback and ideas. ContributorsJohannes Rudolph, Espen Wiborg, Eric Bowman, Petteri Valkonen, Gary Coady, Alexey Alekhin, Andrew Gustafson, Paul Davies, Stanislav Savulchik, Tim Van Laer, Lars Hupel LicenseCopyright (c) 2011-2014 Gerolf Seitz Published under the Apache License 2.0 |
2023-10-27
2022-08-15
2022-08-17
2022-09-23
2022-08-13
请发表评论