com-lihaoyi · lefou · Apr 10, 2025 · Apr 9, 2025 · Apr 9, 2025 · Apr 9, 2025
diff --git a/contrib/artifactory/readme.adoc b/contrib/artifactory/readme.adoc
@@ -20,7 +20,7 @@ object mymodule extends ArtifactoryPublishModule {
 
 Then in your terminal:
 
-[source,bash]
+[source,console]
 ----
 $ mill mymodule.publishArtifactory --credentials $ARTIFACTORY_USER:$ARTIFACTORY_PASSWORD
 ----
diff --git a/contrib/bintray/readme.adoc b/contrib/bintray/readme.adoc
@@ -42,7 +42,7 @@ object mymodule extends BintrayPublishModule {
 
 Then in your terminal:
 
-[source,bash]
+[source,console]
 ----
 $ mill mymodule.publishBintray --credentials $BINTRAY_USER:$BINTRAY_PASSWORD
 ----

diff --git a/contrib/docker/readme.adoc b/contrib/docker/readme.adoc
@@ -23,7 +23,7 @@ object foo extends JavaModule with DockerModule {
 
 Then
 
-[source,bash]
+[source,console]
 ----
 $ mill foo.docker.build
 $ docker run foo

diff --git a/contrib/flyway/readme.adoc b/contrib/flyway/readme.adoc
@@ -32,11 +32,11 @@ This should work regardless of if you are using a mill or sbt project layout.
 
 You can then run common flyway commands like
 
-[source,bash]
+[source,console]
 ----
-mill foo.flywayClean
-mill foo.flywayInfo
-mill foo.flywayMigrate
+> mill foo.flywayClean
+> mill foo.flywayInfo
+> mill foo.flywayMigrate
 ----
 
 CAUTION: You should never hard-code credentials or check them into a version control system.

diff --git a/contrib/jmh/readme.adoc b/contrib/jmh/readme.adoc
@@ -22,12 +22,12 @@ object foo extends ScalaModule with JmhModule {
 
 Here are some sample commands:
 
-[source,bash]
+[source,console]
 ----
-mill foo.runJmh             # Runs all detected jmh benchmarks
-mill foo.listJmhBenchmarks  # List detected jmh benchmarks
-mill foo.runJmh -h          # List available arguments to runJmh
-mill foo.runJmh regexp      # Run all benchmarks matching `regexp`
+> mill foo.runJmh             # Runs all detected jmh benchmarks
+> mill foo.listJmhBenchmarks  # List detected jmh benchmarks
+> mill foo.runJmh -h          # List available arguments to runJmh
+> mill foo.runJmh regexp      # Run all benchmarks matching `regexp`
 ----
 
 For Scala JMH samples see https://github.com/sbt/sbt-jmh/tree/main/plugin/src/sbt-test/sbt-jmh/run/src/main/scala/org/openjdk/jmh/samples[sbt-jmh].
diff --git a/contrib/playlib/readme.adoc b/contrib/playlib/readme.adoc
@@ -316,7 +316,7 @@ The following filesystem layout is expected by default:
 
 `RouterModule` adds the `compileRouter` task to the module:
 
-[source,bash]
+[source,console]
 ----
 $ mill app.compileRouter
 ----

diff --git a/contrib/scoverage/readme.adoc b/contrib/scoverage/readme.adoc
@@ -31,15 +31,15 @@ object foo extends ScoverageModule  {
 In addition to the normal tasks available to your Scala module, Scoverage
 modules introduce a few new tasks and changes the behavior of an existing one.
 
-[source,bash]
+[source,console]
 ----
-mill foo.scoverage.compile              # compiles your module with test instrumentation
-                                        # (you don't have to run this manually, running the test task will force its invocation)
+> mill foo.scoverage.compile              # compiles your module with test instrumentation
+                                          # (you don't have to run this manually, running the test task will force its invocation)
 
-mill foo.test                           # tests your project and collects metrics on code coverage
-mill foo.scoverage.htmlReport           # uses the metrics collected by a previous test run to generate a coverage report in html format
-mill foo.scoverage.xmlReport            # uses the metrics collected by a previous test run to generate a coverage report in xml format
-mill foo.scoverage.xmlCoberturaReport   # uses the metrics collected by a previous test run to generate a coverage report in Cobertura's xml format
+> mill foo.test                           # tests your project and collects metrics on code coverage
+> mill foo.scoverage.htmlReport           # uses the metrics collected by a previous test run to generate a coverage report in html format
+> mill foo.scoverage.xmlReport            # uses the metrics collected by a previous test run to generate a coverage report in xml format
+> mill foo.scoverage.xmlCoberturaReport   # uses the metrics collected by a previous test run to generate a coverage report in Cobertura's xml format
 ----
 
 The measurement data is by default available at `out/foo/scoverage/data/dest`,
@@ -64,13 +64,13 @@ Simply define a `scoverage` module at the root of your project as shown:
 
 This provides you with various reporting functions:
 
-[source,bash]
+[source,console]
 ----
-mill __.test                                 # run tests for all modules
-mill scoverage.htmlReportAll                 # generates report in html format for all modules
-mill scoverage.xmlReportAll                  # generates report in xml format for all modules
-mill scoverage.xmlCoberturaReportAll         # generates report in Cobertura's xml format for all modules
-mill scoverage.consoleReportAll              # reports to the console for all modules
+> mill __.test                                 # run tests for all modules
+> mill scoverage.htmlReportAll                 # generates report in html format for all modules
+> mill scoverage.xmlReportAll                  # generates report in xml format for all modules
+> mill scoverage.xmlCoberturaReportAll         # generates report in Cobertura's xml format for all modules
+> mill scoverage.consoleReportAll              # reports to the console for all modules
 ----
 
 The aggregated report will be available at either `out/scoverage/htmlReportAll.dest/`

diff --git a/contrib/versionfile/readme.adoc b/contrib/versionfile/readme.adoc
@@ -25,22 +25,22 @@ In the example above, that would be `/versionFile/version` relative to the `buil
 
 Create the version file with the initial version number:
 
-[source,bash]
+[source,console]
 ----
 $ 0.1.0-SNAPSHOT > versionFile/version
 ----
 
 Then to write a release version or snapshot version to file:
 
-[source,bash]
+[source,console]
 ----
 $ mill versionFile.setReleaseVersion           # Sets release
 $ mill versionFile.setNextVersion --bump minor # Sets snapshot
 ----
 
 You can also make manual changes in-between:
 
-[source,bash]
+[source,console]
 ----
 $ mill versionFile.setReleaseVersion
 $ echo 0.1.0 > versionFile/version
@@ -90,7 +90,7 @@ then overwrites the previous content in the version file with this new version.
 
 Your version file contains `0.1.0-SNAPSHOT`. In your terminal you do the following:
 
-[source,bash]
+[source,console]
 ----
 $ mill versionFile.setReleaseVersion
 ----
@@ -120,7 +120,7 @@ For a version number `1.2.3` in the version file:
 
 Your version file contains `0.1.0`. In your terminal you do the following:
 
-[source,bash]
+[source,console]
 ----
 $ mill versionFile.setNextVersion --bump minor
 ----
@@ -141,7 +141,7 @@ The version to write to the version file.
 
 Your version file contains `0.1.0`. In your terminal you do the following:
 
-[source,bash]
+[source,console]
 ----
 $ mill versionFile.setVersion --version 0.5.2-SNAPSHOT
 ----
@@ -152,29 +152,29 @@ This will update the version file to contain `0.5.2-SNAPSHOT`.
 
 If you need to output the version numbers (for example for other CI tools you might use), you can use the following commands:
 
-[source,bash]
+.Show the current version from the version file
+[source,console]
 ----
-# Show the current version from the version file.
 $ mill show versionFile.currentVersion
 ----
 
-[source,bash]
+.Show the version that would be used as release version
+[source,console]
 ----
-# Show the version that would be used as release version.
 $ mill show versionFile.releaseVersion
 ----
 
-[source,bash]
+.Show the version that would be used as next version with the given --bump argument
+[source,console]
 ----
-# Show the version that would be used as next version with the given --bump argument.
 $ mill show versionFile.nextVersion --bump minor
 ----
 
 == VCS operations
 
 The module has an `exec` task that allows you to execute tasks of type `T[Seq[os.proc]]`:
 
-[source,bash]
+[source,console]
 ----
 $ mill mill.contrib.versionfile.VersionFile/exec --procs versionFile.tag
 $ mill mill.contrib.versionfile.VersionFile/exec --procs versionFile.push

diff --git a/developer.adoc b/developer.adoc
@@ -93,23 +93,23 @@ You can reproduce any of the tests manually using `dist.run`, e.g.
 
 **Automated Test**
 
-[source,bash]
+[source,console]
 ----
-./mill "example.javalib.basic[1-simple].local.server"
+> ./mill "example.javalib.basic[1-simple].local.server"
 ----
 
 **Manual Test**
 
-[source,bash]
+[source,console]
 ----
-./mill dist.run example/javalib/basic/1-simple foo.run --text hello
+> ./mill dist.run example/javalib/basic/1-simple foo.run --text hello
 ----
 
 **Manual Test using Launcher Script**
 
-[source,bash]
+[source,console]
 ----
-./mill dist.launcher && (cd example/javalib/basic/1-simple && ../../../../out/dist/launcher.dest/run foo.run --text hello)
+> ./mill dist.launcher && (cd example/javalib/basic/1-simple && ../../../../out/dist/launcher.dest/run foo.run --text hello)
 ----
 
 === Sub-Process Tests *with* Packaging/Publishing
@@ -123,9 +123,9 @@ more to run a test after making a code change.
 
 You can reproduce these tests manually using `dist.installLocal`:
 
-[source,bash]
+[source,console]
 ----
-./mill dist.installLocal && (cd example/basic/1-simple && ../../../mill-assembly.jar run --text hello)
+> ./mill dist.installLocal && (cd example/basic/1-simple && ../../../mill-assembly.jar run --text hello)
 ----
 
 You can also use `dist.native.installLocal` for a Graal Native Image executable,
@@ -162,10 +162,10 @@ thing you want to test that needs those code paths to run.
 
 To test bootstrapping of Mill's own Mill build using a version of Mill built from your checkout, you can run
 
-[source,bash]
+[source,console]
 ----
-./mill dist.installLocal
-ci/patch-mill-bootstrap.sh
+> ./mill dist.installLocal
+> ci/patch-mill-bootstrap.sh
 ----
 
 This creates a standalone assembly at `mill-assembly.jar` you can use, which references jars
@@ -185,7 +185,7 @@ If you have another default shell like zsh or fish, you probably need to invoke
 If you want to install into a different location or a different Ivy repository, you can set its optional parameters.
 
 .Install into `/tmp`
-[source,bash]
+[source,console]
 ----
 $ ./mill dist.installLocal --binFile /tmp/mill --ivyRepo /tmp/millRepo
 ...
@@ -195,15 +195,15 @@ Published 44 modules and installed /tmp/mill
 
 For testing documentation changes locally, you can generate documentation for the current checkout via
 
-[source,bash]
+[source,console]
 ----
 $ ./mill docs.fastPages
 ----
 
 To generate documentation for both the current checkout and earlier versions, you can use
 
 
-[source,bash]
+[source,console]
 ----
 $ ./mill docs.localPages
 ----
@@ -212,7 +212,7 @@ $ ./mill docs.localPages
 
 In case of troubles with caching and/or incremental compilation, you can always restart from scratch removing the `out` directory:
 
-[source,bash]
+[source,console]
 ----
 rm -rf out/
 ----
@@ -221,9 +221,10 @@ rm -rf out/
 
 To run all autofixes and autoformatters:
 
-```bash
-./mill __.fix + mill.javalib.palantirformat.PalantirFormatModule/ + mill.scalalib.scalafmt.ScalafmtModule/scalafmt + mill.kotlinlib.ktlint.KtlintModule/
-```
+[source,console]
+----
+> ./mill __.fix + mill.javalib.palantirformat.PalantirFormatModule/ + mill.scalalib.scalafmt.ScalafmtModule/scalafmt + mill.kotlinlib.ktlint.KtlintModule/
+----
 
 These are run automatically on pull requests, so feel free to `pull` down the changes if you want
 to continue developing after your PR has been autofixed for you.

diff --git a/example/javalib/publishing/5-jlink/build.mill b/example/javalib/publishing/5-jlink/build.mill
@@ -21,9 +21,10 @@ object foo extends JavaModule with JlinkModule {
 // See xref:javalib/module-config.adoc#specifying-main-class[Specifying the Main Class] to learn more on how to influence the inference process.
 // You can explicitly specify a `mainClass` like so in your build file:
 //
-// ```scala
+// [source,scala]
+// ----
 // def mainClass: T[Option[String]] = { Some("com.foo.app.Main") }
-// ```
+// ----
 
 // * It then uses the `jlink` tool, to link the previously created `jlink.jmod` with a runtime image.
 
@@ -37,9 +38,9 @@ object foo extends JavaModule with JlinkModule {
 
 // To use a specific JDK, first set your `JAVA_HOME` environment variable prior to running the build.
 
-// ```
+// ----
 // export JAVA_HOME=/Users/mac/.sdkman/candidates/java/17.0.9-oracle/
-// ```
+// ----
 
 /** Usage
 

diff --git a/example/javalib/publishing/6-jpackage/build.mill b/example/javalib/publishing/6-jpackage/build.mill
@@ -60,9 +60,10 @@ object foo extends JavaModule with JpackageModule {
 // The `JpackageModule` trait will infer most of the options needed to assemble a native
 // package/installer, but you can still customize its output. In our example, we specified:
 //
-// ```scala
+// [source,scala]
+// ----
 // def jpackageType = "pkg"
-//```
+// ----
 //
 // This tells `jpackage` to generate a `.pkg`, which is the native installer format on macOS.
 // Valid values on macOS are: `dmg`, `pkg` and `app-image`.
@@ -74,20 +75,23 @@ object foo extends JavaModule with JpackageModule {
 // On macOS, `jpackageType` accepts 3 values: "dmg" or "pkg" or "app-image" (default).
 //
 // * Setting `def jpackageType = "dmg"` will produce:
+// [source,console]
 // ----
-// ls -l ./out/foo/jpackageAppImage.dest/image
+// > ls -l ./out/foo/jpackageAppImage.dest/image
 // ... foo-1.0.dmg
 // ----
 //
 // * Setting `def jpackageType = "pkg"` will produce:
+// [source,console]
 // ----
-// ls -l ./out/foo/jpackageAppImage.dest/image
+// > ls -l ./out/foo/jpackageAppImage.dest/image
 // ... foo-1.0.pkg
 // ----
 //
 // * Setting `def jpackageType = "app-image"` will produce:
+// [source,console]
 // ----
-// ls -l ./out/foo/jpackageAppImage.dest/image
+// > ls -l ./out/foo/jpackageAppImage.dest/image
 // ... foo.app/
 // ./out/foo/jpackageAppImage.dest/image/foo.app/Contents/MacOS/foo
 // ... foo.Foo readConf

diff --git a/example/large/selective/9-selective-execution/build.mill b/example/large/selective/9-selective-execution/build.mill
@@ -19,15 +19,16 @@
 // For example, if you want to run all tests related to the code changes in a pull
 // request branch, you can do that as follows:
 //
-// ```bash
+// [source,console]
+// ----
 // > git checkout main # start from the target branch of the PR
 //
 // > ./mill selective.prepare
 //
 // > git checkout pull-request-branch # go to the pull request branch
 //
 // > ./mill selective.run __.test
-// ```
+// ----
 //
 // The example below demonstrates selective test execution on a small 3-module Java build,
 // where `bar` depends on `foo` but `qux` is standalone: