Skip to content

Latest commit

 

History

History
306 lines (220 loc) · 8.53 KB

README.md

File metadata and controls

306 lines (220 loc) · 8.53 KB
Raw

Pipelinit - creates complete pipelines for your project

Detects the stack of your project and automatically creates a fully working pipeline configuration for multiple continous integration (CI) platforms (currently supporting GitHub Actions).

Say goodbye to YAML!

Support overview

Pipelinit Support Matrix
Stack Stage GitHub Actions GitLab CI Travis CI
CSS Format ✔️ Coming soon Coming soon
Lint ✔️
HTML Format ✔️
Lint ✔️
JavaScript Format ✔️
Lint ✔️
Test Deno (Node.js comming soon)
Python Lint ✔️

How to install

Download an executable from the Releases page.

If you have Deno installed, an alternative method is the Script installer:

deno install      \
  --unstable      \
  --allow-read=.  \
  --allow-write=. \
  https://raw.githubusercontent.com/pipelinit/pipelinit/v0.1.0-rc.1/pipelinit.ts

How to use

Just run pipelinit on the root of your project's source code and follow the instructions:

pipelinit

Concepts

Pipelinit generates pipeline configuration based on these core concepts:

  • Stacks
  • CI Stage
  • CI Platform

Stacks

A Stack is a set of technologies used by a project, such as programming languages, frameworks, libraries, and tools. Pipelinit introspects a project searching for technologies that a CI pipeline can check.

CI Stage

A Stage is a step in a CI pipeline that performs tasks with similar goals independent from the stack. Each step can have multiple substeps. Pipelinit generates standardized CI pipelines with well-defined stages. The tools that each step uses change to fit the stack but serve the same purpose.

Every stage uses Free or Open Source software.

CI Platform

A CI Platform is a public SaaS or self-hosted solution that runs the CI pipeline. Every platform has its capabilities, features, and configurations. Pipelinit leverages the platform features and generates configuration files to build a pipeline tuned for the chosen platform.

How it works

When you run Pipelinit in the root of a software project:

  1. It checks what kind of files exists there to detect the stacks.
  2. It collects more detailed data about each stack.
  3. It uses that data to build the CI configuration files.

Stages

Which stages are present in the final CI pipeline depends on the identified stacks and their support. You can check a complete reference of supported tools, stacks, and which stages are available to each one further down in this document.

Here is a list of available stages and what is the goal of each one:

Format

The format step checks if the code follows the format style from an automated code formatter.

Formatters are valuable for most programming languages and text files because:

  • It makes the code style looks the same regardless of the project
  • It removes style discussions from code review
  • It free developers from thinking about code style

Lint

The lint step uses static analysis tools to improve overall code quality. It enforces some rules in the code base and can detect bugs before execution.

Linters are valuable for most programming languages and text files because:

  • It helps to build more standardized codebases, which is easier to read and maintain
  • It can prevent some bugs
  • It helps to delete unused code
  • It is a great tool to teach how to write better code

SAST

The SAST (Static application security testing) step uses static analysis tools to improve overall code security. This step is distinct from the Lint step because of the security focus.

One issue with SAST tools is that they generate false positives. That's why the default behavior for this step is to allow failure.

SAST tools are valuable for most applications and libraries because:

  • It prevents vulnerabilities early
  • It improves application reliability
  • It is a great tool to teach how to write safer code

Test

The test step runs automated tests detected in the project.

The scope of this step isn't individual files but the application or library. This stage may start extra services if the application or library requires it.

Any application or library, no matter how small the codebase or the team, benefits from automated tests because:

  • It prevents bugs from (re)appearing
  • It helps to onboard new contributors
  • It's required to refactor the codebase towards something better
  • It documents how the software behaves

The benefits far outweigh the costs.

Detailed stack support

In this section you can check details about what each stack supports.

When one of the supported tools can't be detected, pipelinit generates a pipeline configuration with the tool marked as default. If your project doesn't use one of those tools with custom configurations, the pipeline generated uses sensible defaults from the picked tools.

If this isn't desired, you can disable this with the flag --no-default-stage.

CSS Support

Package Managers

Flavors

Tools

Stage Tools
Format Prettier (default)
Lint stylelint (default)

HTML Support

Package Managers

Flavors

Tools

Stage Tools
Format Prettier (default)
Lint ESLint (default), stylelint

JavaScript Support

Package Managers

Flavors

Runtime

Tools

Stage Tools
Format Prettier (default), Deno
Lint ESLint (default), Deno
Test Deno

Python

Tools

Stage Tools
Lint Flake8

Developmenting and contributing

Pipelinit is built with Deno. To develop, test or build the project, make sure you have Deno installed. You can check how to install it in the official Deno website

Automated testing

To run the project automated tests use:

deno --unstable test --allow-read --coverage=cov_profile

And to check the test coverage use:

deno coverage cov_profile
⚠️ Clear the content from cov_profile between each test run. Otherwise your coverage data may be incorrect.

Building

For details on how to build the @pipelinit/core package or how to compile the CLI executable, refer to the README in their respective directories.