fix formating

README.md

@@ -17,8 +17,11 @@ Based on all of these we create a build plan enlisting projects which we should
 ## Executing community build
 Execution of the community build is handled by the GitHub Actions CI using dedicated jobs. Due to the limitations of the GitHub actions a single job can handle up to 1000 community projects, to test more projects we split them into multiple jobs with with a suffix in the form of single subsequent alphabet character. Based on the popularity of projects expressed in ammount of GitHub stars first 1000 projects are included in community build A, next 1000 projects in build B, etc. 
 
-** The execution of the workflow jobs requires explicit access**, these can be granted by the VirtusLab compiler team. If you don't have access to running GitHub Actions with the jobs listed below contact @WojciechMazur
+---
+**The execution of the workflow jobs requires explicit access**, these can be granted by the VirtusLab compiler team. If you don't have access to running GitHub Actions with the jobs listed below contact @WojciechMazur
 
+---
+
 ### Scheduled 
 [Scheduled Build A](https://github.com/VirtusLab/community-build3/actions/workflows/buildExecuteScheduledWeekly-A.yaml)
 
@@ -28,13 +31,13 @@ The Open Community Build is executed weekly at friday night using the latest ava
 [Custom Build A](https://github.com/VirtusLab/community-build3/actions/workflows/buildExecuteCustom-A.yaml)
 
 The compiler team might be intrested in executing on demand builds with a configured version of Scala to use. For that we can use a dedicated CI workflow run taking a set of arguments:
-    * Custom name of the job (Optional) - a custom string allowing to identified results of the job, would be also used as a buildId when persisting the results in the database. 
-    * Published Scala version to use (Optional) - if non empty the value would be used to determinate an already published version to use, otherwise if left empty, the compiler would be build using the next 2 options.
-    * GitHub repository for compiler (defaults to `lampepfl/dotty`) - when building the compiler this repository would be used to provider the compiler sources
-    * GitHub repository branch (defaults to `main`) - when building the compiler this value would point to the branch in the repository provided in the previous setting, that should be used to build the compiler in the
-    * List of scalacOptions to include (Optional) - comma delimiated list of Scala compiler options to apply for all projects that would be build (best effort, applies only to sbt and scala-cli currently)
-    * List of scalacOptions to exclude (Optional) - comma delimiated list of Scala compiler options to remove for all projects that would be build (best effort, applies only to sbt currently)
-    * Should we create and publish raport (default `false`) - a special option used when running community build for release versions of compiler. Is set to true it would generate a raport and publish it on https://virtuslab.github.io/community-build3/
+- Custom name of the job (Optional) - a custom string allowing to identified results of the job, would be also used as a buildId when persisting the results in the database. 
+- Published Scala version to use (Optional) - if non empty the value would be used to determinate an already published version to use, otherwise if left empty, the compiler would be build using the next 2 options.
+- GitHub repository for compiler (defaults to `lampepfl/dotty`) - when building the compiler this repository would be used to provider the compiler sources
+- GitHub repository branch (defaults to `main`) - when building the compiler this value would point to the branch in the repository provided in the previous setting, that should be used to build the compiler in the
+- List of scalacOptions to include (Optional) - comma delimiated list of Scala compiler options to apply for all projects that would be build (best effort, applies only to sbt and scala-cli currently)
+- List of scalacOptions to exclude (Optional) - comma delimiated list of Scala compiler options to remove for all projects that would be build (best effort, applies only to sbt currently)
+- Should we create and publish raport (default `false`) - a special option used when running community build for release versions of compiler. Is set to true it would generate a raport and publish it on https://virtuslab.github.io/community-build3/
 
 For the full coverage it's recommended to execute all available builds, e.g. `Custom Build A`, `Custom Build B`, etc, by manually starting dedicated sibling workflow jobs using the same arguments. 
 
@@ -49,16 +52,16 @@ Can be used to run the build for a single project using the GitHub coordinates i
 [Bisect build](https://github.com/VirtusLab/community-build3/actions/workflows/buildBisect.yaml)
 
 A workflow dedicated to running a bisect job on a given project, using the published versions of Scala compiler to find 2 last good and first failing nightly release of Scala compiler introducing regression. Based on these the commit based bisect is executed, which builds the compiler for every commit between these 2 releases and used them to find commit introducing regression. Accept most of settings defined for `On demand single-project builds` and the specific ones:
-    * List of project targets to builds - can be used to build only 1 sub-project which is failing, otherwise it would build all projects
-    * Specific version of project to bisect against - if left empty the latest version (defined in the config) would be used
-    * The first version of Scala versions range to test against - to limit minimal version of Scala accepted by project. The project should be able to build using this version of Scala
-    * The last version of Scala versions range to test against - the maximal version of Scala, to limit the ammount of tested version. 
+- List of project targets to builds - can be used to build only 1 sub-project which is failing, otherwise it would build all projects
+- Specific version of project to bisect against - if left empty the latest version (defined in the config) would be used
+- The first version of Scala versions range to test against - to limit minimal version of Scala accepted by project. The project should be able to build using this version of Scala
+- The last version of Scala versions range to test against - the maximal version of Scala, to limit the ammount of tested version. 
 
 ### Comparing results of 2 build
 [Compare builds](https://github.com/VirtusLab/community-build3/actions/workflows/compare.yaml)
 A workflow dedicated to compare results of 2 historical builds. It would query the database for results of the historical builds and would try to compare them. Accepts following options:
-    * Reference version of Scala
-    * Version of Scala to compare against 
-    * Optional version of reference build id - the buildId is defined when running the custom builds or assigned using the default value
-    * Optional version of build id to compare against - the buildId is defined when running the custom builds or assigned using the default value
+- Reference version of Scala
+- Version of Scala to compare against 
+- Optional version of reference build id - the buildId is defined when running the custom builds or assigned using the default value
+- Optional version of build id to compare against - the buildId is defined when running the custom builds or assigned using the default value