|
|
**Overview and motivation**
This consolidates settings that were previously implemented as
functions and/or implicit conversions into a suite of sbt
autoplugins. The rationale is that this is well-defined pattern by
sbt and allows easy build introspection with standard sbt
functionality (for example, `sbt plugins` will list all active plugins
in a build). Furthermore, it makes it very easy to disable certain
features when required, such as removing linting during development.
**Migration from current version**
All features from the previous version should still be provided by
the changes proposed here. The migration path is quite straight-forward:
- Replace `project.driverService(name)` with
`project.enablePlugins(Service)` (same goes for libraries) and make
sure the project's name corresponds to the service's name
- Linting, which was previously enabled by adding `lintingSettings`
and `formatSettings` to a project, is automatically enabled. It may
be removed by disabling the plugin: `project.dsiablePlugin(Linting)`
All tasks and settings provided by sbt-settings should remain the same.
**Additional features**
An additional feature is that versioning is now handled the same way
between libraries and services; that is, the version is derived from
the latest git tag. Since services may be deployed from the same tag
mutliple times, it is required that versions can be explicitly set to
include additional information, such as a build number from a CI
system. This was previously done interactively, using sbt's `set`
command:
```
export TAG="$(sbt -no-colors version | tail -1 | awk '{ print $2 }').$TRAVIS_BUILD_NUMBER"
sbt "set version := \"$TAG\"" docker:publishLocal
```
While this approach works, it has the downsides of requiring mutliple
sbt invocations.
The changes proposed in this PR will read the version from a VERSION
environment variable first, defaulting to git if
unavailable. Therefore, the additional sbt invocation can be removed
with a CI script similar to the following:
```
export VERSION="$(git describe).$TRAVIS_BUILD_NUMBER""
sbt docker:publishLocal
// use version in other steps
```
Using an autoplugin-based approach may also make it easier to
cross-compile projects to ScalaJS and Native in the future, as support
for them is built into sbt-crossproject.
|
