<commit_before># Lead

Lead is a pipeline tool to automate repeating tasks. It is not a replacement for build tools like Maven, Composer, npm, etc. Instead you should think of it as an orchestration tool with the power of Docker.

The ultimate goal is to allow scripting of pipelines which run everywhere.

## Why Should I Care?

Nowadays basically every CI/CD server allows creating pipelines as code. For example:

- Jenkins: [Pipeline](https://jenkins.io/doc/book/pipeline/) 
- Travis: [travis.yml](https://docs.travis-ci.com/user/getting-started/)
- Bamboo: [Bamboo Specs (since 6.0)](https://confluence.atlassian.com/bamboo/tutorial-create-a-simple-plan-with-bamboo-specs-894743911.html)
- GoCD: [Pipeline as Code](https://docs.gocd.io/17.4.0/advanced_usage/pipelines_as_code.html)
- ... and more

But these all have some downsides:

- These just work on the CI/CD server they were designed for
  - **no cross-compability**
- Inconvenient way of "programming" pipelines (as configuration files)
  - **not very flexible**
  - **limited features**
- These only work on the server side
  - **locally developers can not make use of these**
  - **hard to test and debug**

**So why should a developer on her/his machine not make use of the CI/CD pipeline which has all the information about building, testing and running the code?** After all most of the time she/he uses the same commands and tools locally as on the server. This discrepancy can cause a "works on my machine" mindset and create confusion about different results when running on the server. In the worst case developers **are not able to resolve the failing build** because they can not reconstruct the differences between their local development stack and the one running on the server.

Lead to the rescue. It supports **environment independent builds** by running every task/job/step (or whatever you may call it) inside Docker containers. Hence no more version discrepancies for programming languages, build tools, os, etc. Every run of Lead is repeatable and returns the same result. **You can run the same command locally and on the server and get the same result.**

This also encourages the DevOps mindset. Let's be honest, there is always this person in the project responsible for configuring the CI/CD server and/or pipeline. But as developers can and should make use of the pipeline script themselves, they can for the first time **really and directly benefit of having a pipeline script**. Also they are empowered to adjust the pipeline -> creating again benefit for everybody else in the team.

It is also possible to **use Lead with every CI/CD server imaginable**. The only requirements are to be able to run Python and/or Docker (see [Installation](#Installation)). Ever switched your CI/CD server? It is very cumbersome and tedious. But having Lead as your pipeline tool you can easily use any CI/CD server without long configuration sessions or complete rewritings of your current pipeline. Now you can choose your CI/CD server solely by features like usability, design, feedback, performance, etc.

Lead is designed to give you all the **power of a real programming language (Python <3)** and a **fully customizable virtual environment (Docker <3)**. Well, you deserve to see an example of a simple job to get the feeling:

```python
@job(description="Echoing Hello World.")
@docker("ubuntu:16.04")
def hello_world(exec):
  world_str="world".capitalize()
  exit_code, output = exec("""

    echo "Hello {world}!"

  """.format(world=world_str), shell="bash")
``` 
This example is very straightforward and just an appetizer. To learn more you can either start with [installing Lead](#Installation) or jump directly to [Getting Started](#GettingStarted) and even more [Examples](#Examples). If you have a question maybe it is already answered in the [FAQ section](#FAQ).

## Installation

### Prerequisites
<commit_msg>README update - Why should i care - improvements<commit_after># Lead

Lead is a pipeline tool to automate repeating tasks. It is not a replacement for build tools like Maven, Composer, npm, etc. Instead you should think of it as an orchestration tool with the power of Docker.

The ultimate goal is to allow scripting of pipelines which run everywhere.

## Why Should I Care?

Nowadays basically every CI/CD server allows creating pipelines as code. For example:

- Jenkins: [Pipeline](https://jenkins.io/doc/book/pipeline/) 
- Travis: [travis.yml](https://docs.travis-ci.com/user/getting-started/)
- Bamboo: [Bamboo Specs (since 6.0)](https://confluence.atlassian.com/bamboo/tutorial-create-a-simple-plan-with-bamboo-specs-894743911.html)
- GoCD: [Pipeline as Code](https://docs.gocd.io/17.4.0/advanced_usage/pipelines_as_code.html)
- ... and more

But these all have some downsides:

- These just work on the CI/CD server they were designed for
  - **no cross-compability**
- Inconvenient way of "programming" pipelines (as configuration files)
  - **not very flexible**
  - **limited features**
- These only work on the server side
  - **locally developers can not make use of these**
  - **hard to test and debug**

**So why should a developer on her/his machine not make use of the CI/CD pipeline which has all the information about building, testing and running the code?** After all most of the time she/he uses the same commands and tools locally as on the server. But she/he executes these commands manually. This discrepancy can cause a "works on my machine" mindset. Additionally it creates confusion about different build results when it fails on the server but not locally. In the worst case developers **are not able to resolve the failing build** because they can not reconstruct the differences between their local development stack and the one running on the server.

Lead to the rescue. It supports **environment independent builds** by running every task/job/step (or whatever you may call it) inside Docker containers. Hence no more version discrepancies for programming languages, build tools, operating system, etc. Every run of Lead is repeatable and returns the same result. **You can run the same command locally and on the server and get the same result.**

This also encourages the DevOps mindset. Let's be honest, there is always this person in the project responsible for configuring the CI/CD server and/or pipeline. But as developers can and should make use of the pipeline script and Lead themselves, they can for the first time **really and directly benefit of having a pipeline script**. Also they are empowered to adjust the pipeline -> creating again benefit for everybody else in the team.

It is also possible to **use Lead with every CI/CD server imaginable**. The only requirements are to be able to run Python and/or Docker (see [Installation](#Installation)). Ever switched your CI/CD server? It is very cumbersome and tedious. But having Lead as your pipeline tool you can easily use any CI/CD server without long configuration sessions or complete rewritings of your current pipeline. Now you can choose your CI/CD server solely by features like usability, design, feedback, performance, etc.

Lead is designed to give you all the **power of a real programming language (Python <3)** and a **fully customizable virtual environment (Docker <3)**. Maybe the following short example gives you an idea of the possibilities:

```python
@job(description="Echoing Hello World.")
@docker("ubuntu:16.04")
def hello_world(exec):
  world_str="world".capitalize()
  exit_code, output = exec("""

    echo "Hello {world}!"

  """.format(world=world_str), shell="bash")
  return exit_code
``` 
This example is very simple and just an appetizer. To learn more you can either start with [installing Lead](#Installation) or jump directly to [Getting Started](#GettingStarted) and even more [Examples](#Examples). If you have a question maybe it is already answered in the [FAQ section](#FAQ).

## Installation

### Prerequisites

{'fraction_non_alphanumeric': 0.0771356783919598, 'fraction_numerical': 0.0052763819095477385, 'mean_word_length': 4.528472222222222, 'pattern_counts': {'":': 0, '<': 7, '<?xml version=': 0, '>': 5, 'https://': 8, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1708641', 'n_tokens_mistral': 2122, 'n_tokens_neox': 1966, 'n_words': 1102}