@zio.dev/zio-sbt 0.3.10 → 0.4.0-alpha.1

package/index.md

@@ -12,7 +12,7 @@ _ZIO SBT_ is an sbt plugin for ZIO projects. It provides high-level SBT utilitie
 Add the following lines to your `plugin.sbt` file:
 
 ```scala
-addSbtPlugin("dev.zio" % "zio-sbt-website" % "0.3.10")
+addSbtPlugin("dev.zio" % "zio-sbt-website" % "0.4.0-alpha.1")
 ```
 
 Then you can enable it by using the following code in your `build.sbt` file:
@@ -31,3 +31,57 @@ ZIO SBT Website is an SBT plugin that has the following tasks:
 - `sbt publishToNpm`— publishes documentation inside the `docs` directory to the npm registry.
 - `sbt generateGithubWorkflow`— generates GitHub workflow which publishes documentation for each library release.
 - `sbt generateReadme`— generate README.md file from `docs/index.md` and sbt setting keys.
+
+## ZIO SBT CI Plugin
+
+ZIO SBT CI is an sbt plugin which generates a GitHub workflow for a project, making it easier to set up continuous integration (CI) pipelines for Scala projects. With this plugin, developers can streamline their development workflow by automating the testing and deployment process, reducing manual effort and errors. The plugin is designed to work seamlessly with sbt, the popular build tool for Scala projects, and integrates smoothly with GitHub Actions, the CI/CD platform provided by GitHub.
+
+ZIO SBT CI provides a simple and efficient way to configure, manage, and run CI pipelines, helping teams to deliver high-quality software faster and with greater confidence.
+
+ZIO SBT CI plugin generates a default GitHub workflow that includes common CI tasks such as building, testing, and publishing artifacts. However, users can also manually customize the workflow. This plugin is designed to be flexible and extensible, making it easy for users to tailor the workflow to their specific needs. Additionally, the plugin also provides tons of optional sbt settings that users can modify to change various aspects of the generated workflow. Overall, ZIO SBT CI plugin strikes a balance between automation and flexibility, allowing users to automate their CI process while still giving them control over how the workflow is generated.
+
+### Getting Started
+
+To use ZIO SBT CI plugin, add the following lines to your `plugins.sbt` file:
+
+```scala
+addSbtPlugin("dev.zio" % "zio-sbt-ci" % "0.4.0-alpha.1")
+
+resolvers ++= Resolver.sonatypeOssRepos("public")
+```
+
+Then in your `build.sbt` file, enable the plugin by adding the following line:
+
+```scala
+enablePlugins(ZioSbtCiPlugin)
+```
+
+Now you can generate a Github workflow by running the following command:
+
+```bash
+sbt ciGenerateGithubWorkflow
+```
+
+The `ciTargetScalaVersions` setting key is used to define a mapping of project names to the Scala versions that should be used for testing phase of continuous integration (CI).
+
+In the example provided, `ciTargetScalaVersions` is defined at the `ThisBuild` level, meaning that the setting will apply to all projects within the build. The setting defines a Map where the key is the name of the current project, obtained by calling the `id` method on the `thisProject` setting, and the value is a sequence of Scala versions obtained from the `crossScalaVersions` of each submodule setting.
+
+By default, sbt will run the test task for each project in the build using the default `ThisBuild / crossScalaVersion` (not implemented yet). However, this may not be sufficient for projects that need to be tested against multiple Scala versions, such as libraries or frameworks that support different versions of Scala. In such cases, the `ciTargetScalaVersions` setting can be used to define the Scala versions supported by each submodule.
+
+For example, suppose we have a project with the name "submoduleA" and we want to test it against Scala `2.11.12` and `2.12.17`, and for the "submoduleB" we want to test it against Scala `2.12.17` and `2.13.10` and `3.2.2`, We can define the `ciTargetScalaVersions` setting as follows:
+
+```scala
+ThisBuild / ciTargetScalaVersions := Map(
+    "submoduleA" -> Seq("2.11.12", "2.12.17"),
+    "submoduleB" -> Seq("2.12.17", "2.13.10", "3.2.2")
+  )
+```
+
+To simplify this process, we can populate the versions using each submodule's crossScalaVersions setting as follows:
+
+```scala
+ThisBuild / ciTargetScalaVersions := Map(
+  (submoduleA / thisProject).value.id -> (submoduleA / crossScalaVersions).value,
+  (submoduleB / thisProject).value.id -> (submoduleB / crossScalaVersions).value
+)
+```

package/package.json

@@ -2,5 +2,5 @@
   "name": "@zio.dev/zio-sbt",
   "description": "ZIO SBT Documentation",
   "license": "Apache-2.0",
-  "version": "0.3.10"
+  "version": "0.4.0-alpha.1"
 }