Agola: CI/CD Redefined
Go to file
Simone Gotti 39829f1ec4 runservice: save step exitstatus in run.
For every step save also the command exit status.
2019-09-17 14:35:37 +02:00
.agola *: update to go 1.13 2019-09-10 14:08:55 +02:00
cmd types: use a global When type 2019-09-05 09:37:27 +02:00
doc update example in devel doc 2019-08-19 10:16:54 +02:00
examples agolademo: update config paths to /data 2019-07-02 10:56:29 +02:00
internal runservice: save step exitstatus in run. 2019-09-17 14:35:37 +02:00
scripts Add makefile 2019-02-21 15:59:16 +01:00
services runservice: save step exitstatus in run. 2019-09-17 14:35:37 +02:00
tests tests: add wait function in place of sleep 2019-08-30 12:50:49 +02:00
util *: export clients and related types 2019-08-02 12:02:01 +02:00
webbundle Add webbundle implementation 2019-02-21 16:08:02 +01:00
.dockerignore Add dockerfile 2019-02-21 16:10:30 +01:00
.gitignore Initial commit 2019-02-21 15:56:50 +01:00
Dockerfile *: update to go 1.13 2019-09-10 14:08:55 +02:00
LICENSE Initial commit 2019-02-21 15:56:50 +01:00
Makefile *: use vanity url 2019-07-01 11:40:20 +02:00
README.md README.md: update screenshots 2019-09-03 15:12:49 +02:00
go.mod *: update to go 1.13 2019-09-10 14:08:55 +02:00
go.sum go mod: update golang.org/x/xerrors 2019-07-24 15:23:33 +02:00

README.md

Agola

Build Status Discourse

CI/CD redefined

For an introduction to agola you can take a look at this post

Try it

See the agolademo example

Features

  • Easy to install and manage.
  • Scalable and High Available: go from a single instance (single process) deployment to a distributed deployment.
  • Deploy anywhere: Kubernetes, IaaS, bare metal and execute the "tasks" anywhere (currently containers executors like docker or orchestrators and Kubernetes, but easily extensible to future technologies or VMs instead of containers).
  • Support any language, deployment system etc... (just use the right image)
  • Integrate with multiple git providers at the same time: you could add repos from github, gitlab, gitea (and more to come) inside the same agola installation.
  • Use it to manage the full development lifecycle: from build to deploy.
  • Tasks Workflows (that we called Runs) with ability to achieve fan-in, fan-out, matrixes etc..., everything containerized to achieve maximum reproducibility.
  • Git based workflow: the run definition is committed inside the git repository (so everything is tracked and reproducible). A run execution is started by a git action (push, pull-request).
  • Design it with the ability to achieve at most once runs: during a deployment to production we don't want multiple concurrent execution of the deploy...
  • Restartable and reproducible Runs (restart a run from scratch or from failed tasks using the same source commit, variables etc...)
  • User Direct Runs: give every user the power to test their software using the same run definition used when pushing to git/opening a pull request inside the Agola installation with just one command like if they were running tests locally (without requiring a super powerful workstation).
  • Testable "Runs" (what is a CI/CD environment if you cannot test your changes to the Runs definitions?): use the same run definition but use a powerful secrets and variables system to access different resources (environments, docker registries etc...).
  • Don't try to extend YAML to be a templating language but use a real templating language (as of now jsonnet) to easily generate the run configuration without side effects.
  • An advanced permissions system (work in progress).
  • Dependency Caching to speed up tasks

Documentation

https://agola.io/doc/

Local development

See how to develop agola

Contributing to Agola

Agola is an open source project under the Apache 2.0 license, and contributions are gladly welcomed! To submit your changes please open a pull request.

Contacts

  • For bugs and feature requests file an issue
  • For general discussion about using and developing Agola, join the agola forum