Enterprise-Grade CI/CD and DevOps Automation Open Source Platform

# CDS: Continuous Delivery Service

[![Go Report Card](https://goreportcard.com/badge/github.com/ovh/cds)](https://goreportcard.com/report/github.com/ovh/cds)
[![GoDoc](https://godoc.org/github.com/ovh/cds/sdk/cdsclient?status.svg)](https://godoc.org/github.com/ovh/cds/sdk/cdsclient)

<img align="right" src="https://raw.githubusercontent.com/ovh/cds/master/logo-background.png" width="25%">

CDS is an Enterprise-Grade Continuous Delivery & DevOps Automation Platform written in Go(lang).

**This project is under active development**

**[Documentation](https://ovh.github.io/cds/)**


## Intuitive UI
CDS provides an intuitive UI that allows you to build complex workflows, run them and dig into the logs when needed.


 <kbd>
 <img src="./docs/static/images/capture-start.gif" alt="create and run workflow with CDS ui" title="create and run workflow with CDS ui">
 </kbd>
 Create and run workflow with CDS ui.


## The most powerful Command Line for a CI/CD Platform

cdsctl is the CDS Command Line - you can script everything with it, cdsctl also provides some cool commands such as `cdsctl shell` to browse your projects and workflows without the need to open a browser.

[See all cdsctl commands](https://ovh.github.io/cds/docs/components/cdsctl/)


 <img src="./docs/static/images/init_template_as_code.gif" alt="create workflow as code with CDS command line" title="create workflow as code with CDS command line">
 Create workflow as code with CDS command line.


## Want a try?

Docker-Compose is your friend, see [Ready To Run Tutorials](https://ovh.github.io/cds/hosting/ready-to-run/)

## Blog posts and talks

- CDS Introduction: https://blog.ovhcloud.com/how-does-ovh-manage-the-ci-cd-at-scale/
- DataBuzzWord Podcast (French) : https://blog.ovhcloud.com/understanding-ci-cd-for-big-data-and-machine-learning/
- Continuous Delivery and Deployment Workflows with CDS: https://blog.ovhcloud.com/continuous-delivery-and-deployment-workflows-with-cds/
- Talk at conference [Breizhcamp](https://www.breizhcamp.org) to introduce CDS (French): https://www.youtube.com/watch?v=JUzEQuOehv4

## FAQ

### Why CDS? Discover the Origins

- [Self-Service](https://ovh.github.io/cds/about/why_cds/#1-self-service)
- [Horizontal Scalability](https://ovh.github.io/cds/about/why_cds/#2-horizontal-scalability)
- [High Availability](https://ovh.github.io/cds/about/why_cds/#3-high-availability)
- [Pipeline Reutilisability](https://ovh.github.io/cds/about/why_cds/#4-pipeline-reutilisability)
- [Rest API](https://ovh.github.io/cds/about/why_cds/#5-rest-api)
- [Customizable](https://ovh.github.io/cds/about/why_cds/#6-customizable)

### What is a CDS workflow?

Most of the CI/CD Tools play with jobs inside a pipeline. CDS introduces a new concept named `CDS Workflows`.
A [CDS Workflow](https://ovh.github.io/cds/docs/concepts/workflow/) allows you to chain pipelines with triggers.
A [pipeline](https://ovh.github.io/cds/docs/concepts/pipeline/) is structured in sequential [stages](https://ovh.github.io/cds/docs/concepts/pipeline/#stages) containing one or multiple concurrent [jobs](https://ovh.github.io/cds/docs/concepts/job/).


### Can I use it in production?

Yes! CDS is used in production since 2015 @OVH and it launches more than 7M CDS workers per year. You can install the official release available on https://github.com/ovh/cds/releases

CDS provides everything needed to monitor and measure production activity (logs, metrics, monitoring)

### How to backup?

All data are stored in the database - nothing on the filesystem. Just backup your database regularly and you will be safe.

### Need some help?

Core Team is available on [GitHub](https://github.com/ovh/cds/discussions)

### CDS User features

#### Pipeline

Ability to run multiple jobs simultaneously while keeping an isolation between them. [See doc about stages & jobs inside a pipeline](https://ovh.github.io/cds/docs/concepts/pipeline/). A pipeline is started with a context: 0 or 1 application, 0 or 1 environment.

#### Workflow

A Workflow makes it possible to chain the pipelines. This is a key feature of CDS. You can create workflows using one or more pipelines, pipelines that can be linked together with joins or forks.

You can imagine having only one workflow builder and deploying your entire microservice stack. The same pipeline can be used several times in a workflow, you can associate an application or an environment.
You will only have one deployment pipeline and one build pipeline to maintain, even if you have hundreds of applications.

#### Workflow templates

A workflow template allows you to share and reuse workflows across multiple teams. Any user can create a Workflow Template, maintain it as code or from UI, and bulk update a set of workflows with a single action.

As a company, you can offer a predefined catalog of Workflows allowing you to standardize test and deployment practices across all your teams.

This also reduces the maintenance efforts since templates allow a scalable centralized management.

#### Visual configuration with Web UI

You can configure everything with the web UI. Even if you have complex use cases, it's usually easier to create your workflows graphically.

#### Configuration on Git Repository

Pipeline as code is a well-known concept of CI / CD tools. CDS goes a step further and offers workflow as code. This is done by git-pushing using yaml configuration files of your workflow (+ pipeline, + applications, + environment). This is particularly useful as you can test your new workflow on a dev branch, before merging the changes on the master branch.


#### Configuration as code on UI

You can modify your workflow with the UI, you can also modify the configuration by editing the yaml file directly in the UI if you wish. This is an excellent way to learn how to use the workflow-as-code feature.

#### Native Git branching

Ability to launch builds based on a branch pattern. This allows, for example, to deploy dev/* branches to "staging" and deploy the master branch to "prod".

Note that CDS's default behavior is to launch the whole workflow on every git commit. This behavior can be altered using "run conditions".

#### Native GitHub / Bitbucket Server / GitLab / Gerrit integration

2-way integration with most popular git-based products.

1. Ability to get notified and start a build when a change is pushed.
2. Ability to notify the git-based tool of the success/failure of the build.

CDS natively supports GitHub, GitLab, Bitbucket Server, and Gerrit.
The link between your git repo and CDS is via a CDS application: 1 Git repository == a CDS application.
Through this integration, CDS will push the build status of your commits : Building, Success, or Failed.

#### Multiple VCS Support in Pipeline/Job

CDS gives you the possibility to clone from different git repositories within a single workflow. A CDS workflow can involve several different applications - or none if you do not want to have a connection with a git repo.

#### Job's Services

Ability to start ephemeral services (a database, a web server, etc.) to support your job. This is particularly handy while testing your code.

In CDS these services are called Service Prerequisites. You just need to specify the corresponding docker image and run params.

Take a simple example: you have a pipeline that builds a docker image containing your application. Your application needs a redis and a PostgreSQL to work. You can, in a CDS job, put three prerequisite services: a redis, a PostgreSQL, and your application. CDS will take care of making a private network between its services so that they can communicate with each other.
Your CDS job can thus perform integration tests on your application starting with a real database and a real cache.

Please read: https://ovh.github.io/cds/docs/concepts/requirement/requirement_service/

#### Secure Remote Caching

A remote cache is used by a team of developers and/or a continuous integration (CI) system to share build outputs. If your build is reproducible, the outputs from one machine can be safely reused on another machine, which can make builds significantly faster

Doc: https://ovh.github.io/cds/docs/components/worker/cache/

#### Enterprise Notification Bus

As an Enterprise-Grade platform, CDS can send a wide range of its internal events (e.g. build finished) in an event bus.
This event flow can then feed other services (reporting, notifications, etc., ).

#### Built-in Hooks

Ability to launch a workflow manually or with git pushes or via a scheduler or via a webhook.
In addition to the above, CDS can also be triggered using an event bus (kafka or RabbitMQ).

#### Continuous Deployment & Environment Support

Ability to manage multiple environments (e.g. dev/prod/staging) in a secure way with segregated access rights.
In practice, an environment is a set of variables that you can use within your workflows.

With CDS, You can use a deployment pipeline on your preproduction environment and use that same deployment pipeline on your production environment. The ability to deploy to production can be limited to a pre-established group of users.

#### Enterprise-grade permissions / Support of ACLs delegation

Users are free to create groups and manage users in their groups. A group can have the right to read, write and execute their projects and their workflows. You can also restrict the execution of some pipelines to some groups if you wish.

#### Build Artifacts Cloud

If you use CDS as a CI / CD tool, you will probably have built artifacts. CDS jobs are isolated from each other, but you can pass artifacts from one job to another using the Artifact Upload and Artifact Download actions.
At the end of a CDS job, all the files are deleted from the workers. To persist artifacts, CDS can use a Swift Storage or a given filesystem (not recommended though).


#### Tests & Vulnerabilities Reports

CDS clearly displays the results of unit tests and vulnerabilities detected during builds.

#### Self-Service Project Creation

A CDS project is like a tenant. All users can create a CDS project, this project will bring together applications, environments, pipelines and of course workflows.

CDS projects are isolated from one another, but the same group may have access rights to multiple projects if you wish.

#### Execution Environment Customization

A worker model is a worker execution context. Let's say, you need to run a job that requires GoLang v1.11.5. In CDS, you just need to create a Go worker model, containing a go in version 1.11.5.
A worker model can be a docker image, an OpenStack image or a VSphere image.
Although CDS administrators can offer shared worker models, users can create their own template workers if they wish.

#### Self-Service User’s Integrations

On a CDS project, you can add integrations like OpenStack, Kubernetes, etc ... This will offer you features within your workflows. For example, with the Kubernetes integration, you can add your own cluster to your CDS project and thus be able to use the Deploy Application action to deploy your newly built application on your cluster, in helm format if you wish.
You can of course develop your own integrations.

#### Multi-Tenancy

After reading the previous points, you've understood: self-service is everywhere. All users can create their project/workflow/ worker models/workflow templates/actions... And run Jobs in a totally isolated environment. CDS projects are builders, on which you can add integrations. All this allows you to have only one instance of CDS for your entire company.

#### Command Line Interface (cdsctl): 100% of features supported

All you can do with the UI is available via the Command-Line Interface (CLI), named "cdsctl". cdsctl is available on all the OS: Darwin, FreeBSD, Linux, OpenBSD... cdsctl will allow you to create, launch, export, import your workflows, monitor your CDS and navigate through your projects and workflows.
No need to go to the UI of CDS or your repository manager to check the status of your commit, `git push && cdsctl workflow --track` will display your workflow in your command line.

#### REST API & SDK

Do you have even more advanced automation needs, or the desire to develop an application that queries CDS? The [REST API](https://ovh.github.io/cds/development/rest/) and the [SDK](https://ovh.github.io/cds/development/sdk/golang/) will allow you to easily develop your software.

### CDS Administration features

#### Self-Hosting

CDS has been open-source since October 2016. You can install it freely in your company or at home. Some tutorials are available to help you start a CDS, [docker-compose](https://ovh.github.io/cds/hosting/ready-to-run/docker-compose/), [Install with binaries](https://ovh.github.io/cds/hosting/ready-to-run/from-binaries/).

#### High Availability / Scalability / Upgrade without User Downtime

High availability is a very important point for a CI / CD tool. CDS is stateless, nothing is stored on the filesystem. This makes it possible to launch several CDS APIs behind a load balancer. Thus, you can scale the API of CDS to your needs. It also allows upgrades of CDS in a full day without impact on users.
In production @OVH, CDS can be updated several times a day, without impacting users or stopping CDS workers.
Asking your users to stop working while updating the Continuous Delivery tool would be ironic, isn't it? ;-)


#### Built-in Metrics

CDS natively exposes monitoring data. You will be able to feed your instance [prometheus](https://prometheus.io/) or [warp10](https://www.warp10.io/) using [beamium](https://github.com/ovh/beamium).

#### Extensibility Plugins

A CDS job consists of steps. Each step is a built-in type action (script, checkoutApplication, Artifact upload/download...). You can create your actions, using existing actions - or develop your action as a plugin. All languages are supported, as long as the language supports GRPC.

#### OS/Arch Compatibility

CDS is agnostic to languages and platforms. Users can launch Jobs on Linux, Windows, FreeBSD, OS X, Raspberry ... in a Virtual Machine spawn on demand, in a docker container, on a dedicated host.

So, if your company uses multiple technologies, CDS will not be a blocker for building and deploying your internal software.

#### Auto-Scale OnDemand multi-cloud

One of the initial objectives of CDS at OVH: build and deploy 150 applications as a container in less than 7 minutes. This has become a reality since 2015. What is the secret key?
Auto-Scale on Demand!

Thus, you can have hundreds of worker models and when necessary, CDS will start the workers using the hatcheries.

A [hatchery](https://ovh.github.io/cds/docs/components/hatchery/) is like an incubator, it gives birth to the CDS Workers and the right to life and death over them.

Several types of hatchery are available:

 - **[hatchery kubernetes](https://ovh.github.io/cds/docs/integrations/kubernetes/kubernetes_compute/)** starts workers in pods
 - **[hatchery openstack](https://ovh.github.io/cds/docs/integrations/openstack/openstack_compute/)** starts virtual machines
 - **[hatchery swarm](https://ovh.github.io/cds/docs/integrations/swarm/)** starts docker containers
 - **[hatchery vSphere](https://ovh.github.io/cds/docs/integrations/vsphere/)** starts virtual machines
 - **[hatchery local](https://ovh.github.io/cds/docs/components/hatchery/local/)** starts processes on a host

 So yes, buzzwords or not, a multi-cloud Auto-scale OnDemand is a reality with CDS :-)


## License

[3-clause BSD](./LICENSE)

A minimal, local first continuous integration system that uses Docker to run jobs concurrently in stages

# Dot
[![Go Reference](https://pkg.go.dev/badge/github.com/opnlabs/dot.svg)](https://pkg.go.dev/github.com/opnlabs/dot) [![Dot](https://github.com/opnlabs/dot/actions/workflows/main.yml/badge.svg)](https://github.com/opnlabs/dot/actions/workflows/main.yml) [![Go Report Card](https://goreportcard.com/badge/github.com/cvhariharan/dot)](https://goreportcard.com/report/github.com/cvhariharan/dot) [![Codacy Badge](https://app.codacy.com/project/badge/Coverage/1a5800bae3c143c29e3559e3f46bffb1)](https://app.codacy.com/gh/opnlabs/dot/dashboard?utm_source=gh&utm_medium=referral&utm_content=&utm_campaign=Badge_coverage)

A minimal CI. Designed to be local first.

All the jobs run inside docker containers. `Dot` communicates with the Docker daemon using the [Docker client API](https://pkg.go.dev/github.com/docker/docker/client#section-readme).

Refer the project [wiki](https://github.com/opnlabs/dot/wiki) to learn more about dot.


 <img src="images/demo.gif" width="800">


## Features
- Single binary, can run anywhere, on your machine or CI/CD systems
- Multi stage builds with support for build artifacts
- Simple yaml job definition
- Bring your own Docker images. Supports private registries
- Uses plain Docker
- Supports conditional evaluation using expressions

## Installation
Get the latest version from the [releases](https://github.com/opnlabs/dot/releases) section.

The latest version can also be installed using `go`.
```bash
go install github.com/opnlabs/dot@latest
```

### Run using Docker
```bash
docker run -it -v /var/run/docker.sock:/var/run/docker.sock -v /path/to/project:/app ghcr.io/opnlabs/dot:latest -m
```

## Example
This example uses [GoReleaser](https://github.com/goreleaser/goreleaser) to build this project.
```yaml
stages:
 - test
 - security
 - build

jobs:
 - name: Run tests
 stage: test
 image: "docker.io/golang:1.21.3"
 variables:
 - TEST: true
 script:
 - go test ./...
 condition: TEST

 - name: Run checks
 stage: security
 image: "docker.io/golangci/golangci-lint:latest"
 script:
 - golangci-lint run ./...

 - name: Build using Goreleaser
 stage: build
 image: "docker.io/golang:1.21.3-bookworm"
 script:
 - git config --global safe.directory '*'
 - curl -sfL https://goreleaser.com/static/run | bash -s -- build --snapshot
 artifacts:
 - dist
```
Extract the binary once the build is complete.
```
tar xvf .artifacts/artifacts-*.tar
dist/dot_linux_amd64_v1/dot version
```
### Build Dot with Dot
This project can be built with `Dot`. The [dot.yml](dot.yml) file describes all the jobs necessary to build a linux binary. Clone the repo and run

```bash
go run main.go -m
```
This should create an artifact tar file in the `.artifacts` directory with the linux binary `dot`.
The `-m` flag gives `dot` access to the host's docker socket. This is required only if containers are created within `dot`.

 <img src="https://media.tenor.com/rKLBka9zl5UAAAAd/yeah-excellent.gif" width="40%" height="40%">

Drone is a Continuous Integration platform built on Docker, written in Go

# Harness
Harness Open Source is an open source development platform packed with the power of code hosting, automated DevOps pipelines, hosted development environments (Gitspaces), and artifact registries.

## Overview
Harness Open source is an open source development platform packed with the power of code hosting, automated DevOps pipelines, Gitspaces, and artifact registries.


## Running Harness locally
> The latest publicly released docker image can be found on [harness/harness](https://hub.docker.com/r/harness/harness).

To install Harness yourself, simply run the command below. Once the container is up, you can visit http://localhost:3000 in your browser.

```bash
docker run -d \
 -p 3000:3000 \
 -p 3022:3022 \
 -v /var/run/docker.sock:/var/run/docker.sock \
 -v /tmp/harness:/data \
 --name harness \
 --restart always \
 harness/harness
```
> The Harness image uses a volume to store the database and repositories. It is highly recommended to use a bind mount or named volume as otherwise all data will be lost once the container is stopped.

See [developer.harness.io](https://developer.harness.io/docs/open-source) to learn how to get the most out of Harness.

## Where is Drone?

Harness Open Source represents a massive investment in the next generation of Drone. Where Drone focused solely on continuous integration, Harness adds source code hosting, developer environments (gitspaces), and artifact registries; providing teams with an end-to-end, open source DevOps platform.

The goal is for Harness to eventually be at full parity with Drone in terms of pipeline capabilities, allowing users to seamlessly migrate from Drone to Harness.

But, we expect this to take some time, which is why we took a snapshot of Drone as a feature branch [drone](https://github.com/harness/harness/tree/drone) ([README](https://github.com/harness/harness/blob/drone/.github/readme.md)) so it can continue development.

As for Harness, the development is taking place on the [main](https://github.com/harness/harness/tree/main) branch.

For more information on Harness, please visit [developer.harness.io](https://developer.harness.io/).

For more information on Drone, please visit [drone.io](https://www.drone.io/).

## Harness Open Source Development
### Pre-Requisites

Install the latest stable version of Node and Go version 1.20 or higher, and then install the below Go programs. Ensure the GOPATH [bin directory](https://go.dev/doc/gopath_code#GOPATH) is added to your PATH.

Install protobuf
- Check if you've already installed protobuf ```protoc --version```
- If your version is different than v3.21.11, run ```brew unlink protobuf```
- Get v3.21.11 ```curl -s https://raw.githubusercontent.com/Homebrew/homebrew-core/9de8de7a533609ebfded833480c1f7c05a3448cb/Formula/protobuf.rb > /tmp/protobuf.rb```
- Install it ```brew install /tmp/protobuf.rb```
- Check out your version ```protoc --version```

Install protoc-gen-go and protoc-gen-go-rpc:

- Install protoc-gen-go v1.28.1 ```go install google.golang.org/protobuf/cmd/protoc-gen-go@v1.28.1```
(Note that this will install a binary in $GOBIN so make sure $GOBIN is in your $PATH)

- Install protoc-gen-go-grpc v1.2.0 ```go install google.golang.org/grpc/cmd/protoc-gen-go-grpc@v1.2.0```

```bash
$ make dep
$ make tools
```

### Build

First step is to build the user interface artifacts:

```bash
$ pushd web
$ yarn install
$ yarn build
$ popd
```

After that, you can build the Harness binary:

```bash
$ make build
```

### Run

This project supports all operating systems and architectures supported by Go. This means you can build and run the system on your machine; docker containers are not required for local development and testing.

To start the server at `localhost:3000`, simply run the following command:

```bash
./gitness server .local.env
```

### Docker Configuration for Pipelines

Harness pipelines run inside Docker containers. The application automatically negotiates the Docker API version with your Docker daemon, so it works with various Docker versions including Docker Desktop, Rancher Desktop, Colima, and native Docker on Linux.

**Docker Socket Location**

By default, Harness expects the Docker socket at `/var/run/docker.sock`. If you're using an alternative Docker runtime, you may need to configure the socket location:

| Runtime | Socket Location | Configuration |
|---------|-----------------|---------------|
| Docker Desktop | `/var/run/docker.sock` | Works by default |
| Rancher Desktop | `~/.rd/docker.sock` | Create symlink or set `GITNESS_DOCKER_HOST` |
| Colima | `~/.colima/default/docker.sock` | Create symlink or set `GITNESS_DOCKER_HOST` |
| Linux (native) | `/var/run/docker.sock` | Works by default |

**Option 1: Create a symlink (recommended)**
```bash
# For Rancher Desktop
sudo ln -sf ~/.rd/docker.sock /var/run/docker.sock

# For Colima
sudo ln -sf ~/.colima/default/docker.sock /var/run/docker.sock
```

**Option 2: Set environment variable**

Add to your `.local.env`:
```bash
# For Rancher Desktop
GITNESS_DOCKER_HOST=unix:///Users/<username>/.rd/docker.sock

# For Colima
GITNESS_DOCKER_HOST=unix:///Users/<username>/.colima/default/docker.sock
```

**Pinning Docker API Version**

The application automatically negotiates the API version with your Docker daemon. If you need to pin a specific version (e.g., for compatibility testing), you can set:
```bash
GITNESS_DOCKER_API_VERSION=1.45
```

### Auto-Generate Harness API Client used by UI using Swagger
Please make sure to update the autogenerated client code used by the UI when adding new rest APIs.

To regenerate the code, please execute the following steps:
- Regenerate swagger with latest Harness binary `./gitness swagger > web/src/services/code/swagger.yaml`
- navigate to the `web` folder and run `yarn services`

The latest API changes should now be reflected in `web/src/services/code/index.tsx`

# Run Registry Conformance Tests
```
make conformance-test
```
For running conformance tests with existing running service, use:
```
make hot-conformance-test
```

## User Interface

This project includes a full user interface for interacting with the system. When you run the application, you can access the user interface by navigating to `http://localhost:3000` in your browser.

## REST API

This project includes a swagger specification. When you run the application, you can access the swagger specification by navigating to `http://localhost:3000/swagger` in your browser (for raw yaml see `http://localhost:3000/openapi.yaml`).
For registry endpoints, currently swagger is located on different endpoint `http://localhost:3000/registry/swagger/` (for raw json see `http://localhost:3000/registry/swagger.json`). These will be later moved to the main swagger endpoint. 


For testing, it's simplest to just use the cli to create a token (this requires Harness server to run):
```bash
# LOGIN (user: admin, pw: changeit)
$ ./gitness login

# GENERATE PAT (1 YEAR VALIDITY)
$ ./gitness user pat "my-pat-uid" 2592000
```

The command outputs a valid PAT that has been granted full access as the user.
The token can then be send as part of the `Authorization` header with Postman or curl:

```bash
$ curl http://localhost:3000/api/v1/user \
-H "Authorization: Bearer $TOKEN"
```


## CLI
This project includes VERY basic command line tools for development and running the service. Please remember that you must start the server before you can execute commands.

For a full list of supported operations, please see
```bash
$ ./gitness --help
```

## Contributing

Refer to [CONTRIBUTING.md](https://github.com/harness/harness/blob/main/CONTRIBUTING.md)

## License

Apache License 2.0, see [LICENSE](https://github.com/harness/harness/blob/main/LICENSE).

drone

A GitHub Action to track code coverage in your pull requests, with a beautiful HTML preview, for free

# `go-beautiful-html-coverage`
[![Mentioned in Awesome Go](https://awesome.re/mentioned-badge-flat.svg)](https://github.com/avelino/awesome-go)

A GitHub Action to track code coverage in your pull requests, with [a beautiful HTML preview ↗](https://kilianc.github.io/pretender/head/head.html#file0), for free.

<a href="https://www.buymeacoffee.com/kilianciuffolo" target="_blank"><img src="https://cdn.buymeacoffee.com/buttons/v2/default-yellow.png" alt="Buy Me A Coffee" style="height: 60px !important;width: 217px !important;" ></a>

## Usage

To use this action simply add it to your pre-existent ci workflow. A bare minimal example might look like this:

```yaml
name: Go

on:
 push:
 branches: [ "main" ]
 pull_request:
 branches: [ "main" ]

jobs:
 test:
 name: Build and Test
 runs-on: ubuntu-latest
 permissions:
 pull-requests: write # required for posting comments
 contents: write # required for git push
 steps:
 - uses: actions/checkout@v4

 - name: Set up Go
 uses: actions/setup-go@v5

 - name: Test # this should generate cover.out
 run: make test

 - name: Go Beautiful HTML Coverage
 uses: 'gha-common/go-beautiful-html-coverage@v1'
```

## How it works

This GHA expects `cover.out` to be present in the root of your repo at runtime. `cover.out` is usually generated by `go test` when passing the `-coverprofile=cover.out` flag:

```sh
go test -coverprofile=cover.out ./...
```

For examples on how you might do that you can peak at [`go-test-app/Makefile`](./Makefile), or some of my other go projects like [`pretender`](https://github.com/kilianc/pretender/blob/main/Makefile#L44-L57) and [`base-go-cli`](https://github.com/kilianc/base-golang-cli/blob/main/Makefile#L76-L92).

Once your test has ran and `cover.out` has been generated, the GHA does the following:

1. Create and push [new orphan branch](https://github.com/gha-common/go-beautiful-html-coverage/tree/cover) if one doesn't exist.
1. Generate `cover.html` and `cover.txt` from `cover.out`.
1. Customize `cover.html` and rename it `<sha>.html`.
1. `git-push` the `<sha>.html` file to the orphan branch. This will trigger a `GitHub Pages` deployment.
1. Post a comment to your PR with your code coverage summary (`cover.txt`) and a link to your `<sha>.html`.

### Screenshots

 
<img alt="PR Comment" src="https://github.com/gha-common/go-beautiful-html-coverage/assets/385716/e155c0aa-14ec-4740-9824-f00399e6b170">
<img alt="HTML Preview (Dark)" src="https://github.com/gha-common/go-beautiful-html-coverage/assets/385716/154f0af6-f5a9-4eb5-bc3a-721bab2e4263">
<img alt="HTML Preview (Light)" src="https://github.com/gha-common/go-beautiful-html-coverage/assets/385716/11256803-59c5-45c4-8ad0-e83ac3374388">
 

> [!NOTE]
> In order for the HTML preview links to work, configure `GitHub Pages` in your target repo *(`Settings > Pages`)* to `Deploy from a branch` and pick your target branch, which is, by default, `cover`.
>
> ![GitHub Pages Setup](https://github.com/gha-common/go-beautiful-html-coverage/assets/385716/a14f4df6-6263-4ae3-8685-e7901a1dbbe2)

## Reference

```yaml
- name: Go Beautiful HTML Coverage
 uses: 'gha-common/go-beautiful-html-coverage@v1'
 with:
 # Repository name with owner. For example, actions/checkout.
 # Default: ${{ github.repository }}
 repository: ''

 # The branch to checkout or create and push coverage to.
 # Default: 'cover'
 branch: ''

 # The token to use for pushing to the repository.
 # Default: ${{ github.token }}
 token: ''

 # The relative path of your go project. Useful for monorepos and custom folder structures.
 # Default: ./
 path: ''

 # The minimum % of coverage required.
 # Default: 0
 threshold: ''
```

## Examples

**You can customize the name of the branch that hosts the code coverage files.**

```yaml
- name: Go Beautiful HTML Coverage
 uses: 'gha-common/go-beautiful-html-coverage@v1'
 with:
 branch: 'my-coverage'
```

Just make sure to update the `GitHub Pages` deployment settings to match.

**You can customize the repository that hosts the code coverage files.**

This is helpful if you don't want to clutter your project's repo, or if you want to centralize coverage reporting across multiple repos, or you can't turn on `GitHub Pages` in your project's repo.

```yaml
- name: Go Beautiful HTML Coverage
 uses: 'gha-common/go-beautiful-html-coverage@v1'
 with:
 repository: yourname/coverage
 token: ${{ secrets.GHA_COVERAGE_TOKEN }}
```

Where `GHA_COVERAGE_TOKEN` is a repository secret with a personal token that has write access to `yourname/coverage`.

**You can customize the path to your go project in the repo.**

This is helpful if you have a monorepo with multiple apps, or simply you keep your go files in a subfolder. Just make sure to generate `cover.out` for all your apps before running this GHA.

```yaml
- name: Go Beautiful HTML Coverage
 uses: 'gha-common/go-beautiful-html-coverage@v1'
 with:
 path: ./go-app-01

- name: Go Beautiful HTML Coverage
 uses: 'gha-common/go-beautiful-html-coverage@v1'
 with:
 path: ./go-app-02
```

## License

MIT License, see [LICENSE](./LICENSE.md)

go-beautiful-html-coverage

Use Go 1.18's built-in fuzz testing in GitHub Actions

# go-fuzz-action
GitHub Action for Go fuzz testing. This Action runs Go's built-in fuzz testing, added in Go 1.18, on your code.


## Do you find this useful?

You can sponsor me [here](https://github.com/sponsors/jidicula)!

## Inputs
* `fuzz-time` [**REQUIRED**]: Fuzz target iteration duration, specified as a `time.Duration` (for example `1h30s`). Corresponds to `-fuzztime` flag for the `go test` command. **Ensure this is less than your job/workflow timeout**.
* `packages` [optional]: Run fuzz test on these packages. Corresponds to the `[packages]` input for the `go test` command.
 * Default: `.`
* `fuzz-regexp` [optional]: Run the fuzz test matching the regular expression. Corresponds to the `-fuzz` flag for the `go test` command.
 * Default: `Fuzz`
* `fuzz-minimize-time` [optional]: Fuzz minimization duration, specified as a `time.Duration` (for example `1h30s`). Corresponds to `-fuzzminimizetime` flag for the `go test` command. If you provide this input, ensure it is less than your job timeout.
 * Default: `10s`
* `go-version` [optional]: Which version of Go to use for fuzzing. This will be passed on to `actions/setup-go@v3`.
 * Default: `1.18`
 
## Returns:
* SUCCESS: if your fuzz tests don't raise a failure within the `fuzz-time` input constraint.
* FAILURE: if your fuzz tests raise a failure within the `fuzz-time` input constraint.
 * The workflow run logs will include instructions on how to download (using the [GitHub CLI](https://cli.github.com)) the failing seed corpus to your local machine for remediation, regardless of run trigger.
 * If you run this Action in a PR workflow, it'll comment these instructions on your PR: <img width="864" alt="image" src="https://user-images.githubusercontent.com/12765385/162630131-9050221e-dc75-4620-aa19-d004d8678074.png">

# Usage
⚠️This Action is not tested on `windows` GitHub Actions runners! Use with `windows` runner OS at your own risk!

Create a `.github/workflows/go-fuzz-test.yml` in your repository containing:


```yaml
name: Go fuzz test
on:
 push:
 pull_request:
jobs:
 fuzz-test:
 name: Fuzz test
 runs-on: ubuntu-latest
 steps:
 - uses: jidicula/go-fuzz-action@v1.1.0
 with:
 fuzz-time: 30s
```

## Fuzz test all packages in repo

If you have multiple packages in your repo and you want to fuzz test them all, create a `.github/workflows/go-fuzz-test.yml` in your repository containing:

```yaml
name: Go fuzz test
on:
 push:
 pull_request:
jobs:
 fuzz-test:
 name: Fuzz test
 runs-on: ubuntu-latest
 steps:
 - uses: jidicula/go-fuzz-action@v1.1.0
 with:
 packages: './...'
 fuzz-time: 30s
```

## Longer minimize time

If you want the fuzz test to spend more time on minimizing the failing input to the smallest possible and most human readable value which will still produce an error, create a `.github/workflows/go-fuzz-test.yml` in your repository containing:

```yaml
name: Go fuzz test
on:
 push:
 pull_request:
jobs:
 fuzz-test:
 name: Fuzz test
 runs-on: ubuntu-latest
 steps:
 - uses: jidicula/go-fuzz-action@v1.1.0
 with:
 packages: './...'
 fuzz-time: 30s
 fuzz-minimize-time: 1m
```

## Fuzz tests with different regexp

If you have fuzz tests that don't begin with `Fuzz` (the default regexp), create a `.github/workflows/go-fuzz-test.yml` in your repository containing:

```yaml
name: Go fuzz test
on:
 push:
 pull_request:
jobs:
 fuzz-test:
 name: Fuzz test
 runs-on: ubuntu-latest
 steps:
 - uses: jidicula/go-fuzz-action@main
 with:
 packages: './...'
 fuzz-time: 30s
 fuzz-minimize-time: 1m
 fuzz-regexp: OtherFuzzRegexp
```

# Example repo

I haven't figured out how to test this adequately within this repo, so you can verify its behaviour here: https://github.com/jidicula/test-go-fuzz-action/pull/2

# Who uses this?

[These public repos](https://github.com/search?o=desc&q=uses%3A+jidicula%2Fgo-fuzz-action+-user%3Ajidicula&s=indexed&type=Code) use this Action.

go-fuzz-action

Automate the semantic versioning of Git repositories

go-semver-release

Test, Build, Sign, and Publish your go binaries from a clean workspace

gomason

# gotestfmt: go test output for humans

> ⚠️ **Action required:** gotestfmt has moved to the `GoTestTools` organization and you need to update your references. Please see the [announcement](https://github.com/GoTestTools/gotestfmt/discussions/46). The old repository will be deleted on January 1, 2023.

Are you tired of scrolling through endless Golang test logs in GitHub Actions (or other CI systems)?

![An animation showcasing that gotestfmt transforms a text log into an interactive log with folding sections.](https://raw.githubusercontent.com/GoTestTools/.github/main/gotestfmt.svg)

Then this is the tool for you. Run it locally, or in any CI system with the following command line like this:

```bash
set -euo pipefail
go test -json -v ./... 2>&1 | tee /tmp/gotest.log | gotestfmt
```

Tadam, your tests will now show up in a beautifully formatted fashion. Plug it into your CI and you're done. Installation is also easy:

**Note:** Please always save the original log. You will need it if you have to file a bug report for gotestfmt.

## Table of Contents

- [Installing](#installing)
- [Setting it up in your CI system](#setting-it-up-in-your-ci-system)
  - [GitHub Actions](#github-actions)
  - [GitLab CI](#gitlab-ci)
  - [CircleCI](#circleci)
  - [Add your own CI](#add-your-own-ci)
- [FAQ](#faq)
    - [How do I make the output less verbose?](#how-do-i-make-the-output-less-verbose)
    - [How do I format the log lines within a test?](#how-do-i-format-the-log-lines-within-a-test)
    - [Why does gotestfmt exit with a non-zero status?](#why-does-gotestfmt-exit-with-a-non-zero-status)
    - [Can I use gotestfmt without `-json`?](#can-i-use-gotestfmt-without--json)
    - [Does gotestfmt work with Ginkgo?](#does-gotestfmt-work-with-ginkgo)
    - [I don't like `gotestfmt`. What else can I use?](#i-dont-like-gotestfmt-what-else-can-i-use)
    - [Who uses `gotestfmt`?](#who-uses-gotestfmt)
- [Architecture](#architecture)
- [Building](#building)
- [License](#license)

## Installing

You can install `gotestfmt` using the following methods.

### Manually

You can download the binary manually from the [releases section](https://github.com/GoTestTools/gotestfmt/releases). The binaries have no dependencies and should run without any problems on any of the listed operating systems.

### Using `go install`

You can install `gotestfmt` using the `go install` command:

```
go install github.com/gotesttools/gotestfmt/v2/cmd/gotestfmt@latest
```

You can then use the `gotestfmt` command, provided that your Go `bin` directory is added to your system path.

### Using a container

You can also run `gotestfmt` in a container. For example:

```
go test -json ./... | docker run ghcr.io/gotesttools/gotestfmt:latest
```

If you have a high volume of requests you may want to mirror the image to your own registry.

## Setting it up in your CI system

We have support for several CI systems, and you can also customize the output to match your system. Gotestfmt detects the CI system based on environment variables. If it can't detect the CI system it will try to create a generic colored test output. You can force the CI output with the `-ci github|gitlab|...` option.

- [GitHub Actions](#github-actions)
- [GitLab CI](#gitlab-ci)
- [CircleCI](#circleci)
- [Add your own](#add-your-own-ci)

### GitHub Actions

For GitHub Actions we provide [gotestfmt-action](https://github.com/gotesttools/gotestfmt-action), making it easy to use. Here's how you can set it up:

```yaml
jobs:
  build:
    name: Test
    runs-on: ubuntu-latest
    steps:
      # Checkout your project with git
      - name: Checkout
        uses: actions/checkout@v2

      # Install Go on the VM running the action.
      - name: Set up Go
        uses: actions/setup-go@v2
        with:
          go-version: 1.16

      # Install gotestfmt on the VM running the action.
      - name: Set up gotestfmt
        uses: gotesttools/gotestfmt-action@v2
        with:
          # Optional: pass GITHUB_TOKEN to avoid rate limiting.
          token: ${{ secrets.GITHUB_TOKEN }}

      # Alternatively, install using go install
      - name: Set up gotestfmt
        run: go install github.com/gotesttools/gotestfmt/v2/cmd/gotestfmt@latest

      # Run tests with nice formatting. Save the original log in /tmp/gotest.log
      - name: Run tests
        run: |
          set -euo pipefail
          go test -json -v ./... 2>&1 | tee /tmp/gotest.log | gotestfmt

      # Upload the original go test log as an artifact for later review.
      - name: Upload test log
        uses: actions/upload-artifact@v2
        if: always()
        with:
          name: test-log
          path: /tmp/gotest.log
          if-no-files-found: error
```

Gotestfmt provides specialized output for GitHub Actions based on the presence of the `GITHUB_WORKFLOW` environment variable. You can also set gotestfmt to run in GitHub Actions mode by providing the `-ci github` option.

In GitHub Actions mode gotestfmt will look for the rendering templates in the `.gotestfmt/github` and `.gotestfmt` folders, which can be [customized](#add-your-own-ci).

### GitLab CI

There are multiple ways to run gotestfmt in GitLab CI. You can simply download it from the [releases section](https://github.com/gotesttools/gotestfmt/releases) and use it that way, but we would recommend creating a custom container image to run the tests as follows:

```Dockerfile
# Include gotestfmt as a base image for building
FROM ghcr.io/gotesttools/gotestfmt:latest AS gotestfmt

# Use the golang base image
FROM golang
# Copy gotestfmt into the golang image
COPY --from gotestfmt /gotestfmt /usr/local/bin/
```

You can then run the tests within this image with the following command:

```bash
go test -json -v ./... | /usr/local/bin/gotestfmt
```

To put it all together, you can use the following `.gitlab-ci.yaml`:

```yaml
docker-build:
  image: docker:latest
  stage: build
  services:
    - docker:dind
  before_script:
    - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" $CI_REGISTRY
  script:
    - |
      docker build -t gotestfmt .
      docker run \
        -v $(pwd):/source \
        -v /tmp:/tmp |
        -e GITLAB_CI=${GITLAB_CI} \
        gotestfmt \
        /bin/sh -c "cd /source; go test -json -v ./... 2>&1 | tee /tmp/gotest.log | /usr/local/bin/gotestfmt"
  artifacts:
    paths:
      - /tmp/gotest.log
    expire_in: 1 week
  rules:
    - if: $CI_COMMIT_BRANCH
      exists:
        - Dockerfile
```

You can, of course, customize this to your liking. We also recommend mirroring the `gotestfmt` image to your local registry to avoid rate limiting errors. See the [GitLab blog](https://about.gitlab.com/blog/2020/10/30/mitigating-the-impact-of-docker-hub-pull-requests-limits/) on how to do this.

Gotestfmt detects running in GitLab CI based on the `GITLAB_CI` environment variable. You can also force gotestfmt to run in GitLab CI mode by passing the `-c gitlab` option.

### CircleCI

There is no special template for CircleCI since it doesn't support advanced features like log folding. You can set up Circle CI by using the `gotestfmt` container directly:

```yaml
version: 2
jobs:
  test:
    docker:
      - image: circleci/golang:1.16
    steps:
      - checkout
      - setup_remote_docker:
          version: 19.03.13
      - run:
          name: Run tests
          command: go test -json -v ./... 2>&1 | tee /tmp/gotest.log | docker run -i ghcr.io/gotesttools/gotestfmt:latest
      - store_artifacts:
          path: /tmp/gotest.log
          destination: gotest.log
workflows:
  version: 2
  build-workflow:
    jobs:
      - test
```

### Add your own CI

You can, of course, customize the output to match your CI system. You can do this creating a folder named `.gotestfmt` in your project and adding the [go template](https://pkg.go.dev/text/template) files below. You can find the default templates in the [.gotestfmt](.gotestfmt) folder in this repository.

When running on a well-known CI system, such as GitHub Actions, gotestfmt will detect that and look in the specific subfolder. If you think a specific CI system should have a custom template, please send us a pull request to this repository.

#### downloads.tpl

This file contains the output fragment showing the package downloads in the Go template format. It has the following variables available:

| Variable     | Type                                 | Description                                                             |
|--------------|--------------------------------------|-------------------------------------------------------------------------|
| `.Failed`    | `bool`                               | Indicates an overall failure.                                           |
| `.Packages`  | `[]Package`                          | A list of packages that have been processed.                            |
| `.StartTime` | `*time.Time`                         | The time the first download line was seen. May be empty.                |
| `.EndTime`   | `*time.Time`                         | The time the last download line was seen. May be empty.                 |
| `.Reason`    | `string`                             | If an extra reason is given for the failure, the text is included here. |
| `.Settings`  | [`RenderSettings`](#render-settings) | The render settings (what to hide, etc, [see below](#render-settings)). |

The `Package` items have the following format:

| Variable   | Type     | Description                                                          |
|------------|----------|----------------------------------------------------------------------|
| `.Package` | `string` | Name of the package. (e.g. `github.com/gotesttools/gotestfmt`) |
| `.Version` | `string` | Version of the package. (e.g. `v1.0.0`)                              |
| `.Failed`  | `bool`   | If the package download has failed.                                  |
| `.Reason`  | `string` | Text explaining the failure.                                         |

#### package.tpl

This template is the output format for the results of a single package and the tests in it. If multiple packages are tested, this template is called multiple times in a row. It has the following fields:

| Variable     | Type                                 | Description                                                                            |
|--------------|--------------------------------------|----------------------------------------------------------------------------------------|
| `.Name`      | `string`                             | Name of the package under test.                                                        |
| `.Result`    | `string`                             | Result of all tests in this package. Can be `PASS`, `FAIL`, or `SKIP`.                 |
| `.Duration`  | `time.Duration`                      | Duration of all test runs in this package.                                             |
| `.Coverage`  | `*float64`                           | If coverage data was provided, this indicates the code coverage percentage.            |
| `.Output`    | `string`                             | Additional output from failures. (e.g. syntax error indications)                       |
| `.TestCases` | `[]TestCase`                         | A list of test case results.                                                           |
| `.Reason`    | `string`                             | Text explaining the failure. Empty in most cases.                                      |
| `.StartTime` | `*time.Time`                         | A pointer to a time object when the package was first seen in the output. May be nil.  |
| `.EndTime`   | `*time.Time`                         | A pointer to the time object when the package was last seen in the output. May be nil. |
| `.Settings`  | [`RenderSettings`](#render-settings) | The render settings (what to hide, etc, [see below](#render-settings)).                |

Test cases have the following format:

| Variable     | Type            | Description                                                                              |
|--------------|-----------------|------------------------------------------------------------------------------------------|
| `.Name`      | `string`        | Name of the test case. May contain slashes (`/`) if subtests are run.                    |
| `.Result`    | `string`        | Result of the test. Can be `PASS`, `FAIL`, or `SKIP`.                                    |
| `.Duration`  | `time.Duration` | Duration of all test runs in this package.                                               |
| `.Output`    | `string`        | Log output from the test.                                                                |
| `.StartTime` | `*time.Time`    | A pointer to a time object when the test case was first seen in the output. May be nil.  |
| `.EndTime`   | `*time.Time`    | A pointer to the time object when the test case was last seen in the output. May be nil. |

#### Render settings

Render settings are available in all templates. They have the following fields:

| Variable                   | Type     | Description                                                                                                         |
|----------------------------|----------|---------------------------------------------------------------------------------------------------------------------|
| `.HideSuccessfulDownloads` | `bool`   | Hide successful package downloads from the output.                                                                  |
| `.HideSuccessfulPackages`  | `bool`   | Hide all packages that have only successful tests from the output.                                                  |
| `.HideEmptyPackages`       | `bool`   | Hide the packages from the output that have no test cases.                                                          |
| `.HideSuccessfulTests`     | `bool`   | Hide all tests from the output that are successful.                                                                 |
| `.ShowTestStatus`          | `bool`   | Show the test status next to the icons (`PASS`, `FAIL`, `SKIP`).                                                    |
| `.Formatter`               | `string` | Path to the formatter to be used. This formatter can be invoked by calling `formatTestOutput outputHere .Settings`. | 

## FAQ

### How do I make the output less verbose?

By default, `gotestfmt` will output all tests and their logs. However, you can use the `-hide` function to hide certain aspects of the output. It accepts a comma-separated list of the following values:

- **`successful-tests`:** Hide successful tests.
- **`successful-downloads`:** Hide successful dependency downloads.
- **`successful-packages`:** Hide packages with only successful tests.
- **`empty-packages`:** Hide packages that have no tests.
- **`all`:** Hide all non-error items.

⚠️ This feature depends on the template you use. If you customized your template please make sure to check the [Render settings](#render-settings) object in your code.

### How do I format the log lines within a test?

Gotestfmt starting with version 2.2.0 supports running external formatters:

```
go test -json -v ./... 2>&1 | gotestfmt -formatter "/path/to/your/formatter"
```

The formatter will be called for each individual test case separately and the entire output of the test case will be passed to the formatter on the standard input. The formatter can then write the modified test output to the standard output. The formatter has 10 seconds to finish the test case, otherwise it will be terminated.

You can find a sample formatter written in Go in [cmd/gotestfmt-formatter/main.go](cmd/gotestfmt-formatter/main.go).

### Why does gotestfmt exit with a non-zero status?

As of version 2.3.0 gotestfmt returns with a non-zero exit status when one or more tests fail. We added this behavior to make sure your CI doesn't pass on failing tests if you forget the `set -euo pipefail` option. You can disable this behavior by passing the `-nofail` parameter in the command line.

### How do I know what the icons mean in the output?

The icons are based on the output of `go test -json`. They map to the values from the [`test2json`](https://pkg.go.dev/cmd/test2json) package (PASS, FAIL, SKIP).

You can use the `-showteststatus` flag to output the words next to the icons.

### Can I use gotestfmt without `-json`?

When running `go test` without `-json` the output does not properly contain the package names for each line. This is not a problem if you are running tests only on a single package, but lines become mixed up when running tests on multiple packages. Version 1 of `gotestfmt` supported the raw output, but version 2 dropped support for it because it results in a lot of unmaintainable code based on an undocumented format.

If you need to use `gotestfmt` without using the `-json` flag, please use version 1 of `gotestfmt`. However, it may break, and we may not be able to fix it.

### Does gotestfmt work with Ginkgo?

[Ginkgo](https://onsi.github.io/ginkgo/) has its own output format which is [not compatible with go test](https://github.com/onsi/ginkgo/issues/639). This choice is understandable because the `go test` output format is not properly documented and is also very difficult to work with. However, this means that **`gotestfmt` does not support Ginkgo.**

But, fear not! Ginkgo has a large number of formats it supports using reporters, such as writing jUnit XML reports. Alternatively, you can [even write your own](https://onsi.github.io/ginkgo/#writing-custom-reporters).

### I don't like `gotestfmt`. What else can I use?

There are more awesome tools out there:

- [gotestsum](https://github.com/gotestyourself/gotestsum)
- [tparse](https://github.com/mfridman/tparse)
- [go-junit-report](https://github.com/jstemmer/go-junit-report)

### Who uses `gotestfmt`?

- [ContainerSSH](https://github.com/containerssh/libcontainerssh)
- [go-ovirt-client](https://github.com/ovirt/go-ovirt-client)
- [go-ovirt-client-log-klog](https://github.com/ovirt/go-ovirt-client-log-klog)
- [...and more!](https://github.com/search?q=gotestfmt&type=code)

*To add your name here simply click the pen icon on top of this box. Please use alphabetic order.*

## Architecture

Gotestfmt takes the output from `go test`, parses it and reformats it with the templates located in the `.gotestfmt` directory, or baked into the application.

This application has 3 main pieces: the tokenizer, the parser, and the renderer. All of them run in separate goroutines and pipeline data using channels.

The **tokenizer** takes the raw output from `go test` and turns it into a stream of events that can be consumed.

The **parser** takes the tokens from the tokenizer and interprets them, constructing logical units for test cases, packages, and package downloads.

Finally, the **renderer** takes the two streams from the parser and renders them into human-readable text templates, which are then streamed out to the main application for writing.

## Building

If you wish to build `gotestfmt` for yourself you'll need at least Go 1.16. You can then build it by running `go build cmd/gotestfmt`.

## License

This project is licensed under the [Unlicense](LICENSE.md), you are free to do with it as you please. It has no external dependencies.


gotestfmt

Go integration for Coveralls.io continuous code coverage tracking system

goveralls
=========

[Go](http://golang.org) integration for [Coveralls.io](http://coveralls.io)
continuous code coverage tracking system.

# Installation

`goveralls` requires a working Go installation (Go-1.13 or higher).

```bash
$ go install github.com/mattn/goveralls@latest
```


# Usage

First you will need an API token.  It is found at the bottom of your
repository's page when you are logged in to Coveralls.io.  Each repo has its
own token.

```bash
$ cd $GOPATH/src/github.com/yourusername/yourpackage
$ goveralls -repotoken your_repos_coveralls_token
```

You can set the environment variable `$COVERALLS_TOKEN` to your token so you do
not have to specify it at each invocation.


You can also run this reporter for multiple passes with the flag `-parallel` or
by setting the environment variable `COVERALLS_PARALLEL=true` (see [coveralls
docs](https://docs.coveralls.io/parallel-build-webhook) for more details).


# Continuous Integration

There is no need to run `go test` separately, as `goveralls` runs the entire
test suite.

## GitHub Actions

[shogo82148/actions-goveralls](https://github.com/marketplace/actions/actions-goveralls) is available on GitHub Marketplace.
It provides the shorthand of the GitHub Actions YAML configure.

```yaml
name: Quality
on: [push, pull_request]
jobs:
  test:
    name: Test with Coverage
    runs-on: ubuntu-latest
    steps:
    - name: Set up Go
      uses: actions/setup-go@v2
      with:
        go-version: '1.16'
    - name: Check out code
      uses: actions/checkout@v2
    - name: Install dependencies
      run: |
        go mod download
    - name: Run Unit tests
      run: |
        go test -race -covermode atomic -coverprofile=covprofile ./...
    - name: Install goveralls
      run: go install github.com/mattn/goveralls@latest
    - name: Send coverage
      env:
        COVERALLS_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      run: goveralls -coverprofile=covprofile -service=github
    # or use shogo82148/actions-goveralls
    # - name: Send coverage
    #   uses: shogo82148/actions-goveralls@v1
    #   with:
    #     path-to-profile: covprofile
```

## Travis CI

### GitHub Integration

Enable Travis-CI on your GitHub repository settings.

For a **public** GitHub repository put bellow's `.travis.yml`.

```yml
language: go
go:
  - tip
before_install:
  - go install github.com/mattn/goveralls@latest
script:
  - $GOPATH/bin/goveralls -service=travis-ci
```

For a **public** GitHub repository, it is not necessary to define your repository key (`COVERALLS_TOKEN`).

For a **private** GitHub repository put bellow's `.travis.yml`. If you use **travis pro**, you need to specify `-service=travis-pro` instead of `-service=travis-ci`.

```yml
language: go
go:
  - tip
before_install:
  - go install github.com/mattn/goveralls@latest
script:
  - $GOPATH/bin/goveralls -service=travis-pro
```

Store your Coveralls API token in `Environment variables`.

```
COVERALLS_TOKEN = your_token_goes_here
```

or you can store token using [travis encryption keys](https://docs.travis-ci.com/user/encryption-keys/). Note that this is the token provided in the page for that specific repository on Coveralls. This is *not* one that was created from the "Personal API Tokens" area under your Coveralls account settings.

```
$ gem install travis
$ travis encrypt COVERALLS_TOKEN=your_token_goes_here --add env.global
```

travis will add `env` block as following example:

```yml
env:
  global:
    secure: xxxxxxxxxxxxx
```

### For others:

```
$ go install github.com/mattn/goveralls@latest
$ go test -covermode=count -coverprofile=profile.cov
$ goveralls -coverprofile=profile.cov -service=travis-ci
```

## Drone.io

Store your Coveralls API token in `Environment Variables`:

```
COVERALLS_TOKEN=your_token_goes_here
```

Replace the `go test` line in your `Commands` with these lines:

```
$ go install github.com/mattn/goveralls@latest
$ goveralls -service drone.io
```

`goveralls` automatically use the environment variable `COVERALLS_TOKEN` as the
default value for `-repotoken`.

You can use the `-v` flag to see verbose output from the test suite:

```
$ goveralls -v -service drone.io
```

## CircleCI

Store your Coveralls API token as an [Environment Variable](https://circleci.com/docs/environment-variables).

In your `circle.yml` add the following commands under the `test` section.

```yml
test:
  pre:
    - go install github.com/mattn/goveralls@latest
  override:
    - go test -v -cover -race -coverprofile=/home/ubuntu/coverage.out
  post:
    - /home/ubuntu/.go_workspace/bin/goveralls -coverprofile=/home/ubuntu/coverage.out -service=circle-ci -repotoken=$COVERALLS_TOKEN
```

For more information, See https://docs.coveralls.io/go

## Semaphore

Store your Coveralls API token in `Environment Variables`:

```
COVERALLS_TOKEN=your_token_goes_here
```

More instructions on how to do this can be found in the [Semaphore documentation](https://semaphoreci.com/docs/exporting-environment-variables.html).

Replace the `go test` line in your `Commands` with these lines:

```
$ go install github.com/mattn/goveralls@latest
$ goveralls -service semaphore
```

`goveralls` automatically use the environment variable `COVERALLS_TOKEN` as the
default value for `-repotoken`.

You can use the `-v` flag to see verbose output from the test suite:

```
$ goveralls -v -service semaphore
```

## Jenkins CI

Add your Coveralls API token as a credential in Jenkins (see [Jenkins documentation](https://www.jenkins.io/doc/book/using/using-credentials/#configuring-credentials)).

Then declare it as the environment variable `COVERALLS_TOKEN`:
```groovy
pipeline {
    agent any
    stages {
        stage('Test with coverage') {
            steps {
                sh 'go test ./... -coverprofile=coverage.txt -covermode=atomic'
            }
        }
        stage('Upload to coveralls.io') {
            environment {
                COVERALLS_TOKEN     = credentials('coveralls-token')
            }
            steps {
                sh 'goveralls -coverprofile=coverage.txt'
            }
        }
    }
}
```

See also [related Jenkins documentation](https://www.jenkins.io/doc/book/pipeline/jenkinsfile/#for-secret-text-usernames-and-passwords-and-secret-files).

It is also possible to let goveralls run the code coverage on its own without providing a coverage profile file.

## TeamCity

Store your Coveralls API token in `Environment Variables`:

```
COVERALLS_TOKEN=your_token_goes_here
```

Setup build steps:

```
$ go install github.com/mattn/goveralls@latest
$ export PULL_REQUEST_NUMBER=%teamcity.build.branch%
$ goveralls -service teamcity -jobid %teamcity.build.id% -jobnumber %build.number%
```

`goveralls` will automatically use the environment variable `COVERALLS_TOKEN` as the
default value for `-repotoken`.

You can use the `-v` flag to see verbose output.


## Gitlab CI

Store your Coveralls API token as an [Environment Variable](https://docs.gitlab.com/ee/ci/variables/#create-a-custom-variable-in-the-ui) named `COVERALLS_TOKEN`.

```yml
test:
  timeout: 30m
  stage: test
  artifacts:
    paths:
      - coverage.txt
  dependencies:
    - build:env
  when: always
  script:
    - go test -covermode atomic -coverprofile=coverage.txt ./...
    - go install github.com/mattn/goveralls@latest
    - goveralls -service=gitlab -coverprofile=coverage.txt
```

## Coveralls Enterprise

If you are using Coveralls Enterprise and have a self-signed certificate, you need to skip certificate verification:

```shell
$ goveralls -insecure
```

# Authors

* Yasuhiro Matsumoto (a.k.a. mattn)
* haya14busa

# License

under the MIT License: http://mattn.mit-license.org/2016


goveralls

Fast website link checker in Go, see [alternatives](https://github.com/lycheeverse/lychee#features)

# Muffet

[![GitHub Action](https://img.shields.io/github/actions/workflow/status/raviqqe/muffet/test.yaml?branch=main&style=flat-square)](https://github.com/raviqqe/muffet/actions)
[![Codecov](https://img.shields.io/codecov/c/github/raviqqe/muffet.svg?style=flat-square)](https://codecov.io/gh/raviqqe/muffet)
[![Docker](https://img.shields.io/docker/pulls/raviqqe/muffet?style=flat-square)](https://hub.docker.com/r/raviqqe/muffet)
[![License](https://img.shields.io/github/license/raviqqe/muffet.svg?style=flat-square)](https://github.com/raviqqe/muffet/blob/main/LICENSE)

![demo](img/demo.gif)

Muffet is a website link checker which scrapes and inspects all pages in a website recursively.

## Features

- Massive speed
- High compatibility with web browsers
- Different tag support (`a`, `img`, `link`, `script`, etc)
- Multiple output formats (text, JSON, and JUnit XML)

## Install

```sh
go install github.com/raviqqe/muffet/v2@latest
```

For more information, see [the install page](https://raviqqe.github.io/muffet/install).

## Usage

```sh
muffet https://shady.bakery.hotland
```

For more information including usage on Docker and GitHub Actions, see [the usage page](https://raviqqe.github.io/muffet/usage).

## License

[MIT](https://github.com/raviqqe/muffet/blob/main/LICENSE)


muffet

Woodpecker is a community fork of the Drone CI system

# Woodpecker


 <a href="https://github.com/woodpecker-ci/woodpecker/">
 <img alt="Woodpecker" src="docs/static/img/logo.svg" width="220"/>
 </a>

 

 <a href="https://ci.woodpecker-ci.org/repos/3780" title="Pipeline Status">
 <img src="https://ci.woodpecker-ci.org/api/badges/3780/status.svg" alt="Pipeline Status">
 </a>
 <a href="https://codecov.io/gh/woodpecker-ci/woodpecker">
 <img src="https://codecov.io/gh/woodpecker-ci/woodpecker/branch/main/graph/badge.svg" alt="Code coverage">
 </a>
 <a href="https://translate.woodpecker-ci.org/engage/woodpecker-ci/">
 <img src="https://translate.woodpecker-ci.org/widgets/woodpecker-ci/-/ui/svg-badge.svg" alt="Translation status" />
 </a>
 <a href="https://matrix.to/#/#woodpecker:matrix.org" title="Join the Matrix space at https://matrix.to/#/#woodpecker:matrix.org">
 <img src="https://img.shields.io/matrix/woodpecker:matrix.org?label=matrix" alt="Matrix space">
 </a>
 <a href="https://goreportcard.com/report/go.woodpecker-ci.org/woodpecker/v3" title="Go Report Card">
 <img src="https://goreportcard.com/badge/go.woodpecker-ci.org/woodpecker/v3" alt="Go Report Card">
 </a>
 <a href="https://pkg.go.dev/go.woodpecker-ci.org/woodpecker/v3" title="go reference">
 <img src="https://pkg.go.dev/badge/go.woodpecker-ci.org/woodpecker/v3" alt="go reference">
 </a>
 <a href="https://github.com/woodpecker-ci/woodpecker/releases/latest" title="GitHub release">
 <img src="https://img.shields.io/github/v/release/woodpecker-ci/woodpecker?sort=semver" alt="GitHub release">
 </a>
 <a href="https://hub.docker.com/r/woodpeckerci/woodpecker-server" title="Docker pulls">
 <img src="https://img.shields.io/docker/pulls/woodpeckerci/woodpecker-server" alt="Docker pulls">
 </a>
 <a href="https://opensource.org/licenses/Apache-2.0" title="License: Apache-2.0">
 <img src="https://img.shields.io/badge/License-Apache%202.0-blue.svg" alt="License: Apache-2.0">
 </a>
 <a href="https://bestpractices.coreinfrastructure.org/projects/5309">
 <img src="https://bestpractices.coreinfrastructure.org/projects/5309/badge" alt="OpenSSF best practices">
 </a>
 <a href="https://results.pre-commit.ci/repo/github/179344069" title="pre-commit.ci">
 <img src="https://results.pre-commit.ci/badge/github/woodpecker-ci/woodpecker/main.svg" alt="pre-commit.ci">
 </a>

 

Woodpecker is a simple, yet powerful CI/CD engine with great extensibility.

![woodpecker](docs/woodpecker.png)

## Installation & Resources

Woodpecker can be installed in various ways (see the [Installation Instructions](https://woodpecker-ci.org/docs/administration/general)) and runs with SQLite as database by default.
It requires around 100 MB of RAM (Server) and 30 MB (Agent) at runtime in idle mode.

## Support

You can support the project by becoming a backer on [Open Collective](https://opencollective.com/woodpecker-ci#category-CONTRIBUTE) or via [GitHub Sponsors](https://github.com/sponsors/woodpecker-ci).

<a href="https://opencollective.com/woodpecker-ci" target="_blank"><img src="https://opencollective.com/woodpecker-ci/backers.svg?width=890" alt="Open Collective backers"></a>

## Documentation

Our documentation can be found at <https://woodpecker-ci.org/docs/intro>.

## Translation

We have a self-hosted [Weblate](https://weblate.org/en/) instance at [translate.woodpecker-ci.org](https://translate.woodpecker-ci.org).

An overview of the current translation state is available at <https://translate.woodpecker-ci.org/projects/woodpecker-ci/#languages>.

## Public Woodpecker Instances

Woodpecker is used as the main CI/CD engine at [Codeberg](https://codeberg.org), an alternative Git hosting platform with a focus on privacy and free software development.

## Plugins

Woodpecker can be extended via plugins.
The [plugin overview website](https://woodpecker-ci.org/plugins) helps browsing available plugins.
It combines both plugins by the Woodpecker core team and community-maintained ones.

## Star History

[![Star History Chart](https://api.star-history.com/svg?repos=woodpecker-ci/woodpecker&type=Date)](https://star-history.com/#woodpecker-ci/woodpecker&Date)

## License

Woodpecker is Apache 2.0 licensed.
The source files have a header indicating which license they are under and what copyrights apply.

Everything in `docs/` is licensed under the Creative Commons Attribution-ShareAlike 4.0 International Public License.

woodpecker

<img height="80" src="https://user-images.githubusercontent.com/1796022/87736445-6b94d200-c7d8-11ea-8f98-fb0d5bf87081.png" />


# Abstruse CI

[![Discord](https://img.shields.io/discord/786173138181685248.svg?logo=discord&logoColor=fff&label=Discord&color=7389d8)](https://discord.gg/dfDXn8dPEA)
[![Go Report Card](https://goreportcard.com/badge/github.com/bleenco/abstruse)](https://goreportcard.com/report/github.com/bleenco/abstruse)

**Abstruse CI** is a lightweight, yet powerful distributed CI/CD written in Golang. Its default configuration uses single node cluster with n workers, however, this cluster can be easily extended with more nodes if necessary.

This is the branch for v2.0.0 or later. If you are looking for Node.JS based v1.x.x version please check [here](https://github.com/bleenco/abstruse/tree/v1).

![Screenshot](https://user-images.githubusercontent.com/1796022/87736550-af87d700-c7d8-11ea-9e9a-c23c2b5e02d1.png)

## Check Out Live Demo

Go to <https://ci.abstruse.app> and login with username `demo@abstruse.app` and password `abstruse`.

Note: A demo user has only read permissions and can't add new repositories.

## Get the Demo Running Locally

If you are interested about the status of this project, the easiest way to get Abstruse 2.x running is:

```sh
git clone https://github.com/bleenco/abstruse.git
cd abstruse
docker-compose -f configs/demo/default/docker-compose.yml up -d
```

You can also build docker images locally:

```sh
make docker
docker-compose -f configs/demo/default/docker-compose.yml up -d
```

This command will run `abstruse-server` with a single worker node `abstruse-worker` and MySQL database.
You should be able to open up the installation wizard in your browser at <http://localhost> and finish the setup.

## Building the Project from Source

To build the project from source, first clone or download repository, then:

```sh
make install_dependencies
make
```

## Development

If you are interested in helping with the new release, you can get the development environment running like:

```sh
make install_dependencies
```

This will install all dependencies for building the project. Please note that you need `Node.JS`, `yarn` and `go` installed, preferably latest releases.

For UI development run:

```sh
cd web/abstruse
yarn start
```

For `abstruse-server` development with live-reload enabled run:

```sh
make dev
```

And for `abstruse-worker` development with live-reload run:

```sh
make dev_worker
```

## License

See the [license](https://github.com/bleenco/abstruse/blob/master/LICENSE).

abstruse

roveralls
=========

A Go recursive coverage testing tool.

[![GoDoc](https://godoc.org/github.com/lawrencewoodman/roveralls?status.svg)](https://godoc.org/github.com/lawrencewoodman/roveralls)
[![Build Status](https://travis-ci.org/lawrencewoodman/roveralls.svg?branch=master)](https://travis-ci.org/lawrencewoodman/roveralls)
[![Build status](https://ci.appveyor.com/api/projects/status/5dcyd6wgu7fxt538?svg=true)](https://ci.appveyor.com/project/lawrencewoodman/roveralls)
[![Coverage Status](https://coveralls.io/repos/lawrencewoodman/roveralls/badge.svg?branch=master)](https://coveralls.io/r/lawrencewoodman/roveralls?branch=master)
[![Go Report Card](https://goreportcard.com/badge/github.com/lawrencewoodman/roveralls)](https://goreportcard.com/report/github.com/lawrencewoodman/roveralls)


roveralls runs coverage tests on a package and all its sub-packages. The coverage profile is output as a single file called 'roveralls.coverprofile' for use by tools such as goveralls.

This tool was inspired by [github.com/go-playground/overalls](https://github.com/go-playground/overalls) written by Dean Karn, but I found it difficult to test and brittle so I decided to rewrite it from scratch. Thanks for the inspiration Dean.

Usage
-----
At its simplest, to test the current package and sub-packages and create a `roveralls.coverprofile` file in the directory that you run the command:

 $ roveralls

To see the help for the command:

 $ roveralls -help

 roveralls runs coverage tests on a package and all its sub-packages. The
 coverage profile is output as a single file called 'roveralls.coverprofile'
 for use by tools such as goveralls.

 Usage of roveralls:
 -covermode count,set,atomic
 Mode to run when testing files: count,set,atomic (default "count")
 -help
 Display this help
 -ignore dir1,dir2,...
 Comma separated list of directory names to ignore: dir1,dir2,... (default ".git,vendor")
 -short
 Tell long-running tests to shorten their run time
 -v	Verbose output


View Output in a Web Browser
----------------------------
To view the code coverage for you packge in a browser:

 $ go tool cover -html=roveralls.coverprofile

Use with goveralls
------------------
 The output of `roveralls` is the same as the the standard `go test -coverprofile=profile.coverprofile` but with multiple files tested in the output file. This can therefore be used with tools such as `goveralls`.

If you wanted to call it from a `.travis.yml` script you could use:

 - $HOME/gopath/bin/roveralls
 - $HOME/gopath/bin/goveralls -coverprofile=roveralls.coverprofile -service=travis-ci

Contributing
------------

If you want to improve this program make a pull request to the [repo](https://github.com/lawrencewoodman/roveralls) on github. Please put any pull requests in a separate branch to ease integration and add a test to prove that it works. If you find a bug, please report it at the project's [issues tracker](https://github.com/lawrencewoodman/roveralls/issues) also on github.


Licence
-------
Copyright (C) 2016, Lawrence Woodman <lwoodman@vlifesystems.com>

This software is licensed under an MIT Licence. Please see the file, LICENCE.md, for details.

roveralls

A GitHub Action which reports issues when test coverage is below set threshold

go-test-coverage

Multi-Package go project coverprofile for tools like goveralls

Package overalls
================

[![Build Status](https://travis-ci.org/go-playground/overalls.svg?branch=master)](https://travis-ci.org/go-playground/overalls)
[![GoDoc](https://godoc.org/github.com/go-playground/overalls?status.svg)](https://godoc.org/github.com/go-playground/overalls)

Package overalls takes multi-package go projects, runs test coverage tests on all packages in each directory and finally concatenates into a single file for tools like goveralls and codecov.io.

Usage and documentation
------
##### Example
	overalls -project=github.com/go-playground/overalls -covermode=count -debug

##### then with other tools such as [goveralls](https://github.com/mattn/goveralls)
	goveralls -coverprofile=overalls.coverprofile -service semaphore -repotoken $COVERALLS_TOKEN
	
##### or [codecov.io](https://github.com/codecov/example-go)
	mv overalls.coverprofile coverage.txt
	export CODECOV_TOKEN=###
 	bash <(curl -s https://codecov.io/bash)


##### note:
1. goveralls and codecover currently do not calculate coverage the same way as `go tool cover` see [here](https://github.com/mattn/goveralls/issues/103) and [here](https://github.com/codecov/example-go/issues/13).

2. overalls (and go test) by default will not calculate coverage "across" packages. E.g. if a test in package A covers code in package B overalls will not count it. You may or may not want this depending on whether you're more concerned about unit test coverage or integration test coverage. To enable add the coverpkg flag.
 `overalls -project=github.com/go-playground/overalls -covermode=count -debug -- -coverpkg=./...`

```shell
$ overalls -help

usage: overalls -project=[path] -covermode[mode] OPTIONS -- TESTOPTIONS

overalls recursively traverses your projects directory structure
running 'go test -covermode=count -coverprofile=profile.coverprofile'
in each directory with go test files, concatenates them into one
coverprofile in your root directory named 'overalls.coverprofile'

OPTIONS
 -project
	Your project path as an absolute path or relative to the '$GOPATH/src' directory
	example: -project=github.com/go-playground/overalls

 -covermode
 Mode to run when testing files.
 default:count

OPTIONAL

 -ignore
 A comma separated list of directory names to ignore, relative to project path.
 example: -ignore=[.git,.hiddentdir...]
 default: '.git'

 -debug
 A flag indicating whether to print debug messages.
 example: -debug
 default:false

 -concurrency
 Limit the number of packages being processed at one time.
 The minimum value must be 2 or more when set.
 example: -concurrency=5
 default: unlimited
```

TESTOPTIONS

 Any flags after `--` will be passed as-is to `go test`.
 For example:

```bash
overalls -project=$PROJECT -debug -- -race -v
```

Will call `go test -race -v` under the hood in addition to the `-coverprofile`
commands.

How to Contribute
------

Make a pull request.

If the changes being proposed or requested are breaking changes, please create an issue.

License
------
Distributed under MIT License, please see license file in code for more details.

The Best Go Libraries For Continuous Integration (15)

CDS

dot