diff --git a/.gitignore b/.gitignore index 18a6d6df..85717934 100644 --- a/.gitignore +++ b/.gitignore @@ -1,2 +1,4 @@ # IntelliJ .idea + +site diff --git a/.nojekyll b/.nojekyll deleted file mode 100644 index e69de29b..00000000 diff --git a/Dockerfile b/Dockerfile new file mode 100644 index 00000000..e2c9117f --- /dev/null +++ b/Dockerfile @@ -0,0 +1,10 @@ +FROM node:9.4.0 + +WORKDIR /svc/cirrus-ci-docs +EXPOSE 8080 + +RUN npm install -g serve@6.4.9 + +ADD site/ /svc/cirrus-ci-docs/ + +CMD exec serve /svc/cirrus-ci-docs/ --port 8080 diff --git a/_coverpage.md b/_coverpage.md deleted file mode 100644 index 2776fef2..00000000 --- a/_coverpage.md +++ /dev/null @@ -1,17 +0,0 @@ -![logo](media/cirrus-labs-logo.svg) - -# Cirrus CI Beta - -> Continuous Integration built for the cloud. - -* Pay for resources as you use them with per second billing -* Bring your VM images and Docker containers -* Up to 96 CPUs and 1433GB of Memory -* Linux and [Windows](docs/supported-computing-services.md#windows-support) support -* SSDs and GPUs - -[Pricing](pricing.md) -[Get Started](overview.md) - - -![color](#212121) diff --git a/_navbar.md b/_navbar.md deleted file mode 100644 index b421f42c..00000000 --- a/_navbar.md +++ /dev/null @@ -1 +0,0 @@ -- [Cirrus CI Builds UI](https://cirrus-ci.com/) diff --git a/_sidebar.md b/_sidebar.md deleted file mode 100644 index 434676ca..00000000 --- a/_sidebar.md +++ /dev/null @@ -1,11 +0,0 @@ -- [Overview](overview.md) -- [Quick Start](quick-start.md) -- [Pricing](pricing.md) -- [Life of a Cirrus CI build](docs/build-life.md) -- [Writing Tasks](docs/writing-tasks.md) -- [Supported Computing Services](docs/supported-computing-services.md) -- [Examples](examples.md) -- [FAQ](faq.md) -- [Terms of Service](terms.md) -- [Privacy Policy](privacy.md) -- [Support](support.md) diff --git a/app.yaml b/app.yaml new file mode 100644 index 00000000..ce2a1243 --- /dev/null +++ b/app.yaml @@ -0,0 +1,2 @@ +runtime: custom +env: flex diff --git a/privacy.md b/docs/about/privacy.md similarity index 100% rename from privacy.md rename to docs/about/privacy.md diff --git a/support.md b/docs/about/support.md similarity index 100% rename from support.md rename to docs/about/support.md diff --git a/terms.md b/docs/about/terms.md similarity index 100% rename from terms.md rename to docs/about/terms.md diff --git a/media/cirrus-ci-communication.svg b/docs/assets/images/cirrus-ci-communication.svg similarity index 99% rename from media/cirrus-ci-communication.svg rename to docs/assets/images/cirrus-ci-communication.svg index 18c9f3ac..70824483 100644 --- a/media/cirrus-ci-communication.svg +++ b/docs/assets/images/cirrus-ci-communication.svg @@ -10,7 +10,7 @@ - - \ No newline at end of file + diff --git a/docs/assets/images/favicon.ico b/docs/assets/images/favicon.ico new file mode 100644 index 00000000..b12500e8 Binary files /dev/null and b/docs/assets/images/favicon.ico differ diff --git a/docs/assets/images/logo.svg b/docs/assets/images/logo.svg new file mode 100644 index 00000000..329786ed --- /dev/null +++ b/docs/assets/images/logo.svg @@ -0,0 +1,17 @@ + + + + cirrus-logo + Created with Sketch. + + + + + diff --git a/faq.md b/docs/faq.md similarity index 64% rename from faq.md rename to docs/faq.md index 74720540..b5760e73 100644 --- a/faq.md +++ b/docs/faq.md @@ -3,7 +3,7 @@ #### Is Cirrus CI a delivery platform? Cirrus CI is not positioned as a delivery platform but can be used as one for many general use cases by having -[Dependencies](docs/writing-tasks.md#dependencies) between tasks and using [Conditional Task Execution](docs/writing-tasks.md#conditional-task-execution): +[Dependencies](guide/writing-tasks.md#dependencies) between tasks and using [Conditional Task Execution](guide/writing-tasks.md#conditional-task-execution): ```yaml lint_task: @@ -26,6 +26,6 @@ publish_task: We are planning to spend Q1 and Q2 of 2018 on [GA](https://en.wikipedia.org/wiki/Software_release_life_cycle#General_availability_(GA)) of Cirrus CI and on support for AWS and Azure. We are going to revisit Mac OS support in Q3 2018. Cirrus CI has everything -for running Mac OS builds except a [computing service](docs/supported-computing-services.md) that can effectively -schedule Mac OS VMs. Please [let us know](support.md) if there is such a service and we can try to work together to bring +for running Mac OS builds except a [computing service](guide/supported-computing-services.md) that can effectively +schedule Mac OS VMs. Please [let us know](about/support.md) if there is such a service and we can try to work together to bring Mac OS support earlier :wink:. diff --git a/docs/build-life.md b/docs/guide/build-life.md similarity index 87% rename from docs/build-life.md rename to docs/guide/build-life.md index 2461f59a..848e49da 100644 --- a/docs/build-life.md +++ b/docs/guide/build-life.md @@ -8,7 +8,7 @@ After build creation Cirrus CI will use GitHub APIs to download a content of `.c will parse it and create corresponding tasks defined in the configuration file. These tasks defined in `.cirrus.yml` file will be dispatched within Cirrus CI to different services responsible for scheduling on -[supported computing service](docs/supported-computing-services.md). A scheduling service will use appropriate APIs to +[supported computing service](supported-computing-services.md). A scheduling service will use appropriate APIs to schedule a VM instance or a Docker container on the particular computing service. The scheduling service will also configure start-up script that downloads Cirrus CI agent, configures and starts it. Cirrus CI agent is a self-contained executable written in Go which means it can be executed anywhere. @@ -18,7 +18,7 @@ of the commands upon execution. Once task finishes the same scheduling service will clean up a VM or a container. -![](media/cirrus-ci-communication.svg) +![](/assets/images/cirrus-ci-communication.svg) Image above is a diagram of how Cirrus CI schedules a task on Google Cloud Platform. Blue arrows represent API calls and green arrow represents unidirectional communication between @@ -27,6 +27,6 @@ an agent inside a VM or a container and Cirrus CI. Other things like health checking of the agent and GitHub status reporting are happening at same time as a task is running but the main flow was described above. Straight forward and nothing magical. :sweat_smile: -For any question please use official [support channels](support.md). +For any question please use official [support channels](/about/support.md). diff --git a/examples.md b/docs/guide/examples.md similarity index 89% rename from examples.md rename to docs/guide/examples.md index 3a7d0bbe..147b302e 100644 --- a/examples.md +++ b/docs/guide/examples.md @@ -8,7 +8,7 @@ a pre-configured user and as a result don't have `HOME` environment variable pre ### Caching -To preserve caches between Gradle runs simply add a [cache instruction](docs/writing-tasks.md#cache-instruction) as shown below. +To preserve caches between Gradle runs simply add a [cache instruction](writing-tasks.md#cache-instruction) as shown below. Trick here is to clean up `~/.gradle/caches` folder in the very end of a build. Gradle creates some unique nondeterministic files in `~/.gradle/caches` folder on every run which breaks Cirrus CI check wherever a cache entry has changed during a build. @@ -27,7 +27,7 @@ check_task: ### Build Cache -Here is how [HTTP Cache](docs/writing-tasks.md#http-cache) can be used with Gradle simply by adding following lines to `settings.gradle`: +Here is how [HTTP Cache](writing-tasks.md#http-cache) can be used with Gradle simply by adding following lines to `settings.gradle`: ```groovy ext.isCiServer = System.getenv().containsKey("CI") diff --git a/quick-start.md b/docs/guide/quick-start.md similarity index 76% rename from quick-start.md rename to docs/guide/quick-start.md index bd48ad4b..2a4fec74 100644 --- a/quick-start.md +++ b/docs/guide/quick-start.md @@ -19,5 +19,6 @@ task: That's all! After pushing `.cirrus.yml` a build with all the tasks defined in `.cirrus.yml` file will be created. GitHub status checks for each task will appear momentarily. -?> Please check [a high level overview of what's happening under the hood](docs/build-life.md) when a changed is pushed -and [this guide](docs/writing-tasks.md) to learn more about how to write tasks. +!!! info + Please check [a high level overview of what's happening under the hood](build-life.md) when a changed is pushed + and [this guide](writing-tasks.md) to learn more about how to write tasks. diff --git a/docs/supported-computing-services.md b/docs/guide/supported-computing-services.md similarity index 70% rename from docs/supported-computing-services.md rename to docs/guide/supported-computing-services.md index 38d4f2d6..662f2322 100644 --- a/docs/supported-computing-services.md +++ b/docs/guide/supported-computing-services.md @@ -1,24 +1,26 @@ # Supported Computing Services -For every [task](docs/writing-tasks.md) Cirrus CI start a new Virtual Machine or a new Docker Container on a given compute service. +For every [task](writing-tasks.md) Cirrus CI starts a new Virtual Machine or a new Docker Container on a given compute service. Using a new VM or a new Docker Container each time for running tasks has many benefits: -* *Atomic changes to an environment where tasks are executed.* Everything about a task is configured in `.cirrus.yml` file including -VM image version and Docker Container image version. After commiting changes to `.cirrus.yml` not only new tasks will use the new environment -but also outdated branches will continue using the old configuration. -* *Reproducibility.* Fresh environment guarantees no corrupted artifacts or caches are presented from the previous tasks. -* *Cost efficiency.* Most compute services are offering per-second pricing which makes them ideal for using with Cirrus CI. -Also each task for repository can define ideal amount of CPUs and Memory specific for a nature of the task. No need to manage -pools of similar VMs or try to fit workloads within limits of a given Continuous Integration systems. + + * **Atomic changes to an environment where tasks are executed.** Everything about a task is configured in `.cirrus.yml` file including + VM image version and Docker Container image version. After commiting changes to `.cirrus.yml` not only new tasks will use the new environment + but also outdated branches will continue using the old configuration. + * **Reproducibility.** Fresh environment guarantees no corrupted artifacts or caches are presented from the previous tasks. + * **Cost efficiency.** Most compute services are offering per-second pricing which makes them ideal for using with Cirrus CI. + Also each task for repository can define ideal amount of CPUs and Memory specific for a nature of the task. No need to manage + pools of similar VMs or try to fit workloads within limits of a given Continuous Integration systems. To be fair there are of course some disadvantages of starting a new VM or a container for every task: -* *Virtual Machine Startup Speed.* Starting a VM can take from a few dozen seconds to a minute or two depending on a cloud provider and -a particular VM image. Starting a container on the other hand just takes a few hundred milliseconds! But even a minute -on average for starting up VMs is not a big inconvenience in favor of more stable, reliable and more reproducible CI. -* *Cold local caches for every task execution.* Many tools tend to store some caches like downloaded dependencies locally -to avoid downloading them again in future. Since Cirrus CI always uses fresh VMs and containers such local caches will always -be empty. Performance implication of empty local caches can be avoided by using Cirrus CI features like -[built-in caching mechanism](docs/writing-tasks.md#cache-instruction). Some tools like [Gradle](https://gradle.org/) can -even take advantages of [built-in HTTP cache](docs/writing-tasks.md#http-cache)! + + * **Virtual Machine Startup Speed.** Starting a VM can take from a few dozen seconds to a minute or two depending on a cloud provider and + a particular VM image. Starting a container on the other hand just takes a few hundred milliseconds! But even a minute + on average for starting up VMs is not a big inconvenience in favor of more stable, reliable and more reproducible CI. + * **Cold local caches for every task execution.** Many tools tend to store some caches like downloaded dependencies locally + to avoid downloading them again in future. Since Cirrus CI always uses fresh VMs and containers such local caches will always + be empty. Performance implication of empty local caches can be avoided by using Cirrus CI features like + [built-in caching mechanism](writing-tasks.md#cache-instruction). Some tools like [Gradle](https://gradle.org/) can + even take advantages of [built-in HTTP cache](writing-tasks.md#http-cache)! Please check the list of currently supported cloud compute services below and please see what's [coming next](#coming-soon). @@ -40,18 +42,20 @@ container: Containers on Community Cluster can use maximum 8.0 CPUs and up to 24 Gb of memory. [Custom GKE clusters](#google-kubernetes-engine) don't have that limitation though. -!> Since Community Cluster is shared scheduling times for containers can vary from time to time. Also the smaller a container -require resources faster it will be scheduled. +!!! warning + Since Community Cluster is shared scheduling times for containers can vary from time to time. Also the smaller a container + require resources faster it will be scheduled. ## Google Cloud Cirrus CI can schedule tasks on several Google Cloud Compute services. In order to interact with Google Cloud APIs -Cirrus CI needs permissions. Creating a [service account](https://cloud.google.com/compute/docs/access/service-accounts) +Cirrus CI needs permissions. Creating a [service account](https://cloud.google.com/compute/access/service-accounts) is a common way to safely give granular access to parts of Google Cloud Projects. -!> We do recommend to create a separate Google Cloud project for running CI builds to make sure tests are -isolated from production data. Having a separate project also will show how much money is spent on CI and how -efficient Cirrus CI is :wink: +!!! warning + We do recommend to create a separate Google Cloud project for running CI builds to make sure tests are + isolated from production data. Having a separate project also will show how much money is spent on CI and how + efficient Cirrus CI is :wink: Once you have a Google Cloud project for Cirrus CI please create a service account by running the following command: @@ -60,7 +64,7 @@ gcloud iam service-accounts create cirrus-ci \ --project $PROJECT_ID ``` -Depending on a compute service Cirrus CI will need different [roles](https://cloud.google.com/iam/docs/understanding-roles) +Depending on a compute service Cirrus CI will need different [roles](https://cloud.google.com/iam/understanding-roles) assigned to the service account. But Cirrus CI will always need permissions to Google Cloud Storage to store logs and caches. In order to give Google Cloud Storage permissions to the service account please run: @@ -70,8 +74,9 @@ gcloud projects add-iam-policy-binding $PROJECT_ID \ --role roles/storage.admin ``` -?> By default Cirrus CI will store logs and caches for 30 days but it can be changed by manually configuring a -[lifecycle rule](https://cloud.google.com/storage/docs/lifecycle) for a Google Cloud Storage bucket that Cirrus CI is using. +!!! info + By default Cirrus CI will store logs and caches for 30 days but it can be changed by manually configuring a + [lifecycle rule](https://cloud.google.com/storage/lifecycle) for a Google Cloud Storage bucket that Cirrus CI is using. Now we have a service account that Cirrus CI can use! It's time to let Cirrus CI know about that fact by securely providing a private key for the service account. A private key can be created by running the following command: @@ -81,7 +86,7 @@ gcloud iam service-accounts keys create service-account-credentials.json \ --iam-account cirrus-ci@$PROJECT_ID.iam.gserviceaccount.com ``` -At last create an [encrypted variable](docs/writing-tasks.md#encrypted-variables) from contents of +At last create an [encrypted variable](writing-tasks.md#encrypted-variables) from contents of `service-account-credentials.json` file and add it to the top of `.cirrus.yml` file: ```yaml @@ -124,8 +129,8 @@ Building an immutable VM image with all necessary software pre-configured is a k It makes sure environment where a task is executed is always the same and that no time is spent on useless work like installing a package over and over again for every single task. -There are many ways how one can create a custom image for Google Compute Engine. Please refer to the [official documentation](https://cloud.google.com/compute/docs/images/create-delete-deprecate-private-images). -At Cirrus Labs we are using [Packer](https://www.packer.io/docs/builders/googlecompute.html) to automate building such +There are many ways how one can create a custom image for Google Compute Engine. Please refer to the [official documentation](https://cloud.google.com/compute/images/create-delete-deprecate-private-images). +At Cirrus Labs we are using [Packer](https://www.packer.io/builders/googlecompute.html) to automate building such images. An example of how we use it can be found in [our public GitHub repository](https://github.com/cirruslabs/cirrus-images). #### Windows Support @@ -178,7 +183,7 @@ push_docker_task: #### Preemptible Instances -Cirrus CI can schedule [preemptible](https://cloud.google.com/compute/docs/instances/preemptible) instances with all price +Cirrus CI can schedule [preemptible](https://cloud.google.com/compute/instances/preemptible) instances with all price benefits and stability risks. But sometimes risks of an instance being preempted at any time can be tolerated. For example `gce_instance` can be configured to schedule preemptible instance for non master branches like this: diff --git a/docs/writing-tasks.md b/docs/guide/writing-tasks.md similarity index 91% rename from docs/writing-tasks.md rename to docs/guide/writing-tasks.md index f4dd362b..88671389 100644 --- a/docs/writing-tasks.md +++ b/docs/guide/writing-tasks.md @@ -1,5 +1,3 @@ -# Writing Tasks - Task defines where and how your scripts will be executed. Let's check line-by-line an example of `.cirrus.yml` configuration file first: ```yaml @@ -14,7 +12,7 @@ task: Example above defines a single task that will be scheduled and executed on Community Cluster using `gradle:4.3.0-jdk8` Docker image. Only one user defined script instruction to run `gradle test` will be executed. Pretty simple, isn't it? -A `task` simply defines a [compute service](doc/supported-computing-services.md) to schedule the task on and +A `task` simply defines a [compute service](supported-computing-services.md) to schedule the task on and a sequence of [`script`](#script-instruction) and [`cache`](#cache-instruction) instructions that will be executed. Please read topics below if you want better understand what's doing on in a more complex `.cirrus.yml` configuration file like this: @@ -60,7 +58,7 @@ publish_task: publish_script: yarn run publish ``` -# Script Instruction +## Script Instruction `script` instruction executes commands via `shell` on Unix or `batch` on Windows. `script` instruction can be named by adding a name as a prefix. For example `test_script` or `my_very_specific_build_step_script`. Naming script instructions @@ -78,7 +76,7 @@ check_task: - gradle check ``` -# Background Script Instruction +## Background Script Instruction `background_script` instruction is absolutely the same as `script` instruction but Cirrus CI won't wait for the script to finish and will continue execution of following instructions. @@ -97,7 +95,7 @@ android_test_task: test_script: gradle test ``` -# Cache Instruction +## Cache Instruction `cache` instruction allows to save some folder in cache based on a fingerprint and reuse it during the next execution of the task with the same fingerprint. `cache` instruction can be named the same way as `script` instruction. @@ -119,7 +117,8 @@ will be used as a fingerprint for the given task. By default task name is used a `fingerprint_script` is an optional field that can specify a script that will be executed to populate the cache. `populate_script` should create `folder`. -!> Note that cache folder will be archived and uploaded only in the very end of the task execution once all instructions succeed. +!!! info + Note that a cache folder will be archived and uploaded only in the very end of the task execution once all instructions succeed. Which means the only difference between example above and below is that `yarn install` will always be executed in the example below where in the example above only when `yarn.lock` has changes. @@ -133,7 +132,7 @@ test_task: test_script: yarn run test ``` -# Environment Variables +## Environment Variables Environment variables can be configured under `environment` keyword in `.cirrus.yml` file. Here is an example: @@ -164,7 +163,7 @@ CIRRUS_REPO_CLONE_URL | URL used for cloning. For example `https://github.com/my CIRRUS_WORKING_DIR | Working directory where CIRRUS_HTTP_CACHE_HOST | Host and port number on which [local HTTP cache](#http-cache) can be accessed on -# Encrypted Variables +## Encrypted Variables It is possible to securely add sensitive information to `.cirrus.yml` file. Encrypted variables are only available to builds initialized or approved by users with write permission to a corresponding repository. @@ -172,7 +171,8 @@ builds initialized or approved by users with write permission to a corresponding In order to encrypt a variable go to repository's settings page via clicking settings icon ![](https://storage.googleapis.com/material-icons/external-assets/v4/icons/svg/ic_settings_white_24px.svg) on a repository's main page (for example https://cirrus-ci.org/github/my-organization/my-repository) and follow instructions. -!> Only users with `WRITE` permissions can add encrypted variables to a repository. +!!! warning + Only users with `WRITE` permissions can add encrypted variables to a repository. An encrypted variable will be presented in a form like `ENCRYPTED[qwerty239abc]` which can be safely committed within `.cirrus.yml` file: @@ -186,7 +186,7 @@ publish_task: Cirrus CI encrypts variables with a unique per repository 256-bit encryption key so forks and even repositories within the same organization cannot re-use them. -# Matrix Modification +## Matrix Modification Sometimes it's useful to run the same task against different software versions. Or run different batches of tests based on an environment variable. For cases like these `matrix` modification comes very handy. It's possible to use `matrix` @@ -218,7 +218,8 @@ test_task: test_script: yarn run test ``` -!> `matrix` modification can be used multiple times within a task. +!!! info + `matrix` modification can be used multiple times within a task. `matrix` modification makes it easy to create some pretty complex testing scenarios like this: @@ -241,7 +242,7 @@ test_task: test_script: yarn run $COMMAND ``` -# Dependencies +## Dependencies Sometimes it might be very handy execute some tasks only after successful execution of other tasks. For such cases it's possible specify for a task names of other tasks it depends on with `depends_on` keyword: @@ -260,7 +261,7 @@ publish_task: script: yarn run publish ``` -# Conditional Task Execution +## Conditional Task Execution Some tasks are meant to be executed for master or release branches only. In order to specify a condition when a task should be executed please use `only_if` keyword: @@ -274,7 +275,7 @@ publish_task: Currently only basic operators like `==`, `!=`, `&&`, `||` and unary `!` are supported in `only_if` expression. [Environment variables](#environment-variables) can also be used as usually. -# HTTP Cache +## HTTP Cache For the most cases regular caching mechanism where Cirrus CI caches a folder is more than enough. But modern build systems like [Gradle](https://gradle.org/), [Bazel](https://bazel.build/) and [Pants](https://www.pantsbuild.org/) can take @@ -284,7 +285,8 @@ execution while the build itself is still executing. Cirrus CI agent starts a local caching server and exposes it via `CIRRUS_HTTP_CACHE_HOST` environments variable. Caching server supports `GET`, `POST` and `HEAD` requests to upload, download and check presence of artifacts. -?> If port `12321` is available `CIRRUS_HTTP_CACHE_HOST` will be equal to `localhost:12321`. +!!! info + If port `12321` is available `CIRRUS_HTTP_CACHE_HOST` will be equal to `localhost:12321`. For example running the following command: @@ -300,4 +302,5 @@ myfolder_cache: folder: myfolder ``` -?> To see how HTTP Cache can be used with Gradle's Build Cache please check [this example](examples.md#build-cache). +!!! info + To see how HTTP Cache can be used with Gradle's Build Cache please check [this example](examples.md#build-cache). diff --git a/overview.md b/docs/index.md similarity index 79% rename from overview.md rename to docs/index.md index e5232d55..e5b2fe4b 100644 --- a/overview.md +++ b/docs/index.md @@ -1,14 +1,13 @@ -# Overview - Cirrus CI is a modern continuous-integration-as-a-service solution that takes advantage of cloud computing services. -Cirrus CI allows customers to schedule CI builds on [variety of cloud services](docs/supported-computing-services.md) and +Cirrus CI allows customers to schedule CI builds on [variety of cloud services](guide/supported-computing-services.md) and pay the cloud provider directly and only for the resources used to run CI builds and store build artifacts. For private repositories Cirrus CI takes a [small per-user fee](pricing.md) for scheduling and orchestrating builds. Cirrus CI is free for Open Source projects. -?> [Community Cluster](docs/supported-computing-services.md#community-cluster) is available free of charge -to Open Source community and with no extra fee for private personal repositories. +!!! info + [Community Cluster](guide/supported-computing-services.md#community-cluster) is available free of charge + to Open Source community and with no extra fee for private personal repositories. # Why Cirrus CI @@ -48,13 +47,13 @@ Because of all the problems and inconveniences described above, we decided to bu # Key Highlights -1. Delegates execution directly to [variety of computing services](docs/supported-computing-services.md). +1. Delegates execution directly to [variety of computing services](guide/supported-computing-services.md). 2. Most cloud compute services have per-second billing. 3. Flexible execution environment: any Unix or Windows VM, any Docker container, any amount of CPUs, optional SSDs and GPUs. -4. Simple but very powerful configuration format. Learn more about how to configure tasks [here](docs/writing-tasks.md). Configure things like: - - [Matrix Builds](docs/writing-tasks.md#matrix-modification) - - [Dependencies between tasks](docs/writing-tasks.md#dependencies) - - [Conditional Task Execution](docs/writing-tasks.md#conditional-task-execution) - - [Local HTTP Cache](docs/writing-tasks.md#http-cache) +4. Simple but very powerful configuration format. Learn more about how to configure tasks [here](guide/writing-tasks.md). Configure things like: + - [Matrix Builds](guide/writing-tasks.md#matrix-modification) + - [Dependencies between tasks](guide/writing-tasks.md#dependencies) + - [Conditional Task Execution](guide/writing-tasks.md#conditional-task-execution) + - [Local HTTP Cache](guide/writing-tasks.md#http-cache) -Try Cirrus CI with a [Quick Start](quick-start.md) guide. +Try Cirrus CI with a [Quick Start](guide/quick-start.md) guide. diff --git a/pricing.md b/docs/pricing.md similarity index 61% rename from pricing.md rename to docs/pricing.md index 3e6435fd..c98f43de 100644 --- a/pricing.md +++ b/docs/pricing.md @@ -2,14 +2,14 @@ Cirrus CI is free for Open Source projects. For private projects Cirrus CI is free while in Beta. After public Beta period is over in the end of Q1 2018 Cirrus CI will charge a monthly fee of **$10 per seat** for orchestrating builds on -supported [computing services](docs/supported-computing-services.md). +supported [computing services](guide/supported-computing-services.md). Here is a pricing model of Cirrus CI **after Beta period**: User | Public Repository | Private Repository --- | --- | --- -Person | Free + Access to [Community Cluster](docs/supported-computing-services.md#community-cluster) | $10/month + Access to [Community Cluster](docs/supported-computing-services.md#community-cluster) -Organization | Free + Access to [Community Cluster](docs/supported-computing-services.md#community-cluster) | $10/seat/month +Person | Free + Access to [Community Cluster](guide/supported-computing-services.md#community-cluster) | $10/month + Access to [Community Cluster](guide/supported-computing-services.md#community-cluster) +Organization | Free + Access to [Community Cluster](guide/supported-computing-services.md#community-cluster) | $10/seat/month All payments will go through [GitHub Marketplace](https://github.com/marketplace) and will be billed according to [GitHub Marketplace Terms of Service](https://help.github.com/articles/github-marketplace-terms-of-service/#d-payment-billing-schedule-and-cancellation). diff --git a/index.html b/index.html deleted file mode 100644 index 243e52b0..00000000 --- a/index.html +++ /dev/null @@ -1,55 +0,0 @@ - - - - - Cirrus CI Docs - - - - - - - - - -
- - - - - - - - - - diff --git a/media/cirrus-ci-logo.svg b/media/cirrus-ci-logo.svg deleted file mode 100644 index 7b7bb24a..00000000 --- a/media/cirrus-ci-logo.svg +++ /dev/null @@ -1,25 +0,0 @@ - - - - cirrus-ci-logo - Created with Sketch. - - - - - \ No newline at end of file diff --git a/media/cirrus-labs-logo.svg b/media/cirrus-labs-logo.svg deleted file mode 100644 index 1a8838aa..00000000 --- a/media/cirrus-labs-logo.svg +++ /dev/null @@ -1,14 +0,0 @@ - - - - - - - - - - - diff --git a/mkdocs.yml b/mkdocs.yml new file mode 100644 index 00000000..73726d07 --- /dev/null +++ b/mkdocs.yml @@ -0,0 +1,76 @@ +repo_url: https://github.com/cirruslabs/cirrus-ci-docs + +site_name: Cirrus CI Beta +site_author: Cirrus Labs +site_description: > + Cirrus CI is a modern Continuous Integration system built for the era of cloud computing. + Cirrus CI supports both Linux and Windows environments as well as various cloud computing + services like Kubernetes and Google Cloud Platform. + +google_analytics: ['UA-110620457-1', 'cirrus-ci.org'] +remote_branch: master +strict: true + +theme: + name: 'material' + favicon: 'assets/images/favicon.ico' + logo: 'assets/images/logo.svg' + # Don't include MkDocs' JavaScript + include_search_page: false + search_index_only: true + language: en + palette: + primary: indigo + accent: indigo + font: + text: Roboto + code: Roboto Mono + +markdown_extensions: + - markdown.extensions.admonition + - markdown.extensions.codehilite: + guess_lang: false + - markdown.extensions.def_list + - markdown.extensions.footnotes + - markdown.extensions.meta + - markdown.extensions.toc: + permalink: true + - pymdownx.arithmatex + - pymdownx.betterem: + smart_enable: all + - pymdownx.caret + - pymdownx.critic + - pymdownx.details + - pymdownx.emoji: + emoji_generator: !!python/name:pymdownx.emoji.to_svg + - pymdownx.inlinehilite + - pymdownx.keys + - pymdownx.magiclink + - pymdownx.mark + - pymdownx.smartsymbols + - pymdownx.superfences + - pymdownx.tasklist: + custom_checkbox: true + - pymdownx.tilde + +pages: + - Home: index.md + - User Guide: + - 'Quick Start': guide/quick-start.md + - 'Writing Tasks': guide/writing-tasks.md + - 'Life of a Build': guide/build-life.md + - 'Supported Computing Services': guide/supported-computing-services.md + - 'Examples': guide/examples.md + - Pricing: pricing.md + - FAQ: faq.md + - About: + - 'Support': about/support.md + - 'Privacy': about/privacy.md + - 'Terms of Service': about/terms.md + +extra: + social: + - type: 'github' + link: 'https://github.com/cirrulabs' + - type: 'twitter' + link: 'https://twitter.com/cirrus_labs'