robertdfrench / zoolander-ci Goto Github PK

What is this, a CI system for ants?!

License: Mozilla Public License 2.0

Makefile 13.16% Shell 17.28% HCL 14.87% Rust 53.71% JSONiq 0.98%

zoolander-ci's Introduction

Zoolander CI

Zoolander is a minimal CI environment for the illumos operating system. It provides a single VM which manages CI for a single GitHub project, namely itself.

Zoolander's job is to provide the little green checkmarks next to commits which pass their tests, and to add a little red X next to any commit which fails its tests:

Feel free to browse through this repo's prior commits to see this in action. Per normal GitHub conventions, clicking on either the checkmark or an X next to a commit will provide you with a "Details" link that will show you the console output for that commit's CI run.

Features

Updates commit status when builds start, pass, or fail
Self-deploying. Simply make deploy (with proper AWS credentials)
Dogfood capable! (Zoolander CI is tested via a Zoolander CI instance!)
Runs CI jobs as an unprivileged user (aptly named derek)
Define build pipelines with plain old GNU Make instead of some proprietary format (See Zoolander.mk).
Plaintext browser ui! Who needs Javascript when you have Ctrl-R?

 #######                                                              #####  ### 
      #   ####   ####  #        ##   #    # #####  ###### #####      #     #  #  
     #   #    # #    # #       #  #  ##   # #    # #      #    #     #        #  
    #    #    # #    # #      #    # # #  # #    # #####  #    #     #        #  
   #     #    # #    # #      ###### #  # # #    # #      #####      #        #  
  #      #    # #    # #      #    # #   ## #    # #      #   #      #     #  #  
 #######  ####   ####  ###### #    # #    # #####  ###### #    #      #####  ### 

+------------------------------------------------------------------------------+
|            Refresh your browser to see the latest build output               |
+------------------------------------------------------------------------------+

From https://github.com/robertdfrench/zoolander-ci
   a83e22a..c0140fc  thin-line-banner -> origin/thin-line-banner
OmniOS 5.11	omnios-r151030-632fca26eb	May 2019
/opt/ooce/bin/cargo test

running 11 tests
test http_document::tests::new_has_content_type ... ok
test http_document::tests::headers_is_a_sorted_iterator ... ok
test http_document::tests::return_text_plain ... ok
test http_document::tests::sorted_headers ... ok
test integration::can_read_empty_log ... ok
test integration::can_read_log ... ok
test pathify::tests::normal ... ok
test pathify::tests::short ... ok
test push_event::tests::accept_a_push_event ... ok
test push_event::tests::real_push_event ... ok
test integration::spawns_make ... ok

test result: ok. 11 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

Limitations

Due to a handful of hadrcoded paths, Zoolander CI can currently only test itself. See Milestone 2 for more information about what work remains to make Zoolander easy for others to use.

Zoolander also has some woeful security problems. Webhooks are not delivered over TLS, and the application itself runs as root (although the CI jobs are executed as an unprivileged user). See #14, #12, and #26 for more information about potential solutions to these problems.

Getting Started

This repository is capable of bootstrapping and deploying itself, assuming you have valid AWS credentials and sufficient privileges to create and manage EC2 instance, images, and security groups. You will also need a github account.

Create a GitHub API Token
- You only need the repo:status permission
Configure your AWS Credentials file
Install:
- Packer
- Terraform
- jq
- GNU Make (probably already installed).

Each Makefile in this repo is self-documenting. Just run make help in any directory to describe the available tasks.

Configuring Webhooks

Once you have deployed a zoolander instance, you will need to give it your API token, and point your webhooks to it. To deploy your token (or rotate your token in the event that it needs to change) just run make rotate. You will be prompted to paste in your GitHub API token, and Make will then install it on your zoolander instance.

Finally, to configure the webhook for your repository, go to Settings > Webhooks > Add webhook. The payload URL will look like http://X.X.X.X/zoolander/webhook where X.X.X.X is your Zoolander instance ip. Set the content-type to json, and then click "Add Webhook".

zoolander-ci's People

Contributors

Stargazers

Watchers

zoolander-ci's Issues

Do not want to have to taint the server if provisioner script is updated

Would like Make or terraform one to be aware that this resource needs to be scrapped.

Signal to the GitHub status api that the build is in progress

Supervisor is tied to 'robertdfrench/zoolander-ci'

It will always assume this repository.

Turn FCGI request into local http_document

This blocks #15 since we'll need this form for routing.

Documentation for configuring a repo

Create a token with the right privileges
Deploy your Zoolander instance
Rotate the token on your Zoolander instance
Add the web hook to your repo

This could replace #10 since folks will need a GitHub access token anyhow, and it will be easier for folks in a pickle to re-read documentation that to figure out why terraform didn't configure some repo the way they thought it would.

Should we distinguish deleted push events?

They come in marked deleted, but can this wait till after demo?

Use terraform to configure repo

in the mean time, we can just document the process

Check for password in web hooks

GitHub's web hooks can provide a (hashed) password. Zoolander should check for this as a means of verifying the authenticity of the webhook.

Elastic IP seems to get destroyed very often

Terraform chooses to destroy and recreate the elastic IP at times when it does not attempt this for other resources.

Separate volume for logs?

To keep the logs from evaporating every time the EC2 instance is restarted, should they live in a separate volume which is attached to an instance on each boot?

Let's Encrypt being provisioned before EIP is attached

Might help to put the EIP in the resource definition, or to do provisioning in a second pass.

Wait for DNS to become available before attempting Let's Encrypt

Run FCGI server as unprivileged user

This will narrow the scope of an exploit.

See #9 (comment)

Get a certificate from Let's Encrypt

Requires some kind of solution for DNS

Should `make deploy`imply `git commit`?

This was handy for make check during development, but should not happen during make deploy

Save push events to "pending" files

So we know the ci task has been acknowledged but not yet started

Update docs for TLS and cut a minor release

Consider self-signed TLS cert

Could do this instead of #12 but would need to make sure documentation (#23) reflects that TLS is self-signed, specifically so that GitHub does not validate the certificate when sending web hooks.

Rebuilding instance does not seem to leverage Elastic IP

AMI detection doesn't fail if region undefined

IP of instance is hardcoded

This should maybe check its EC2 instance properties to get the public IP address.

Support optional DNS

DNS can help solve two problems:

#12 (Let's Encrypt)
#23 (Configure a repo to point to CI)

But we don't want to require someone just messing around with the project to have to use DNS, because that requires at least a time investment if not also a little cash. So if it will be supported, it should be optional.

CLONE THE STINKIN REPO

The repo should be fetched after each event

Use floating IP

This will keep the ip and the EC2-provided DNS from changing in the event that the instance needs to be terminated. This should help make #28 and #25 easier to deal with.

Iterate keys in a sorted fashion

The bug in 97d8039 was introduced by the switch to proper HTTP status code in 9eda277. Mitigating this by changing the expected value of the Status field to match the full HTTP status code name will not suffice, because the document is not constructed the same way every time -- like many languages, rust's hash maps do not iterate in the same order between restarts unless forced. So we need to sort the keys and make sure the response documents are rendered the same way every time.

Assing a 'Name' tag to the Elastic IP

Remove 'make check' in favor of 'make deploy' / 'make install'

We aren't doing anything illumos-specific yet, so testing on the deployed system isn't super useful.

We do launch a new fcgi server or replace the existing one.

Deploy GitHub API Token

We'll need this locally for #10 anyhow
We'll need this remotely for calling the status api

Convert job launcher to shell command

This is a bad fit for Make -- does not use any declarative prerequisites, and spits out more debug statements than we really care about.

Confusing EIP output

Outputs:

ip = {
  "dns" = "zoolander-ci.robertdfrench.com"
  "id" = "eipalloc-039b7c92ec580ee1b"
  "ip" = "52.6.63.33"
}
zoolander = 52.4.19.86

So which is the right IP address?

Route GET to log reader

Currently, the greet handler is responding to everything.

This ought to block #7 since it will make it easier to distinguish requests.

Use Refresh header to automatically reload logs

This is a non-standard Netscape header, but it is apparently supported pretty well: https://stackoverflow.com/questions/283752/refresh-http-header

CI Supervisor

A forked process that supervises an individual job
Has credentials to report back to the github API (with the URL for log reading)
should begin by just echoing "hello world" to the logs and then completing, before we start on #6