mirrors/woodpecker
1
0
Fork 0
mirror of https://github.com/woodpecker-ci/woodpecker.git synced 2024-12-26 10:20:29 +00:00
Code Issues Projects Releases Wiki Activity

Merge pull request #1554 from bradrydzewski/master

Browse source 
removing deprecated files [CI SKIP]
This commit is contained in:
Brad Rydzewski 2016-03-30 01:05:02 -07:00
commit f84378667d
45 changed files with 0 additions and 2081 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

18
Makefile
View file

@ -7,24 +7,16 @@ all: gen build
deps:
go get -u golang.org/x/tools/cmd/cover
go get -u golang.org/x/tools/cmd/vet
go get -u github.com/kr/vexp
go get -u github.com/eknkc/amber/...
go get -u github.com/eknkc/amber
go get -u github.com/jteeuwen/go-bindata/...
go get -u github.com/elazarl/go-bindata-assetfs/...
go get -u github.com/dchest/jsmin
go get -u github.com/franela/goblin
go get -u github.com/PuerkitoBio/goquery
go get -u github.com/russross/blackfriday
GO15VENDOREXPERIMENT=1 go get -u github.com/go-swagger/go-swagger/...
gen: gen_static gen_template gen_migrations
gen_static:
mkdir -p static/docs_gen/api static/docs_gen/build
mkdir -p static/docs_gen/api static/docs_gen/plugin
mkdir -p static/docs_gen/api static/docs_gen/setup
mkdir -p static/docs_gen/api static/docs_gen/cli
go generate github.com/drone/drone/static
gen_template:
@ -56,13 +48,3 @@ deb:
mkdir -p contrib/debian/drone/var/cache/drone
cp drone contrib/debian/drone/usr/local/bin
-dpkg-deb --build contrib/debian/drone
vendor:
vexp
docs:
mkdir -p /drone/tmp/docs
mkdir -p /drone/tmp/static
cp -a static/docs_gen/* /drone/tmp/
cp -a static/styles_gen /drone/tmp/static/
cp -a static/images /drone/tmp/static/

0
docs/swagger.yml → api/swagger/files/swagger.yml
View file

236
contrib/generate-api-docs.go
View file

@ -1,236 +0,0 @@
// +build ignore
// This program generates api documentation from a
// swaggerfile using an amber template.
package main
import (
"crypto/md5"
"flag"
"fmt"
"io"
"log"
"os"
"sort"
"github.com/eknkc/amber"
"github.com/go-swagger/go-swagger/spec"
)
var (
templ = flag.String("template", "index.amber", "")
input = flag.String("input", "swagger.json", "")
output = flag.String("output", "", "")
)
func main() {
flag.Parse()
// parses the swagger spec file
spec, err := spec.YAMLSpec(*input)
if err != nil {
log.Fatal(err)
}
swag := spec.Spec()
// create output source for file. defaults to
// stdout but may be file.
var w io.WriteCloser = os.Stdout
if *output != "" {
w, err = os.Create(*output)
if err != nil {
fmt.Fprintf(os.Stderr, "%v\n", err)
return
}
defer w.Close()
}
// we wrap the swagger file in a map, otherwise it
// won't work with our existing templates, which expect
// a map as the root parameter.
var data = map[string]interface{}{
"Swagger": normalize(swag),
}
t := amber.MustCompileFile(*templ, amber.DefaultOptions)
err = t.Execute(w, data)
if err != nil {
log.Fatal(err)
}
}
// Swagger is a simplified representation of the swagger
// document with a subset of the fields used to generate
// our API documentation.
type Swagger struct {
Tags []Tag
}
type Tag struct {
Name string
Ops []Operation
}
type Operation struct {
ID string
Method string
Path string
Desc string
Summary string
Params []Param
Results []Result
}
type Param struct {
Name string
Desc string
Type string
Example interface{}
InputTo string
IsObject bool
}
type Result struct {
Status int
Desc string
Example interface{}
IsObject bool
IsArray bool
}
// normalize is a helper function that normalizes the swagger
// file to a simpler format that makes it easier to work with
// inside the template.
func normalize(swag *spec.Swagger) Swagger {
swag_ := Swagger{}
for _, tag := range swag.Tags {
tag_ := Tag{Name: tag.Name}
// group the paths based on their tag value.
for route, path := range swag.Paths.Paths {
var ops = []*spec.Operation{
path.Get,
path.Put,
path.Post,
path.Patch,
path.Delete,
}
// flatten the operations into an array and convert
// the underlying data so that it is a bit easier to
// work with.
for _, op := range ops {
// the operation must have a tag to
// be rendered in our custom template.
if op == nil || !hasTag(tag.Name, op.Tags) {
continue
}
item := Operation{}
item.Path = route
item.Method = getMethod(op, path)
item.Desc = op.Description
item.Summary = op.Summary
item.ID = fmt.Sprintf("%x", md5.Sum([]byte(item.Path+item.Method)))
// convert the operation input parameters into
// our internal format so that it is easier to
// work with in the template.
for _, param := range op.Parameters {
param_ := Param{}
param_.Name = param.Name
param_.Desc = param.Description
param_.Type = param.Type
param_.IsObject = param.Schema != nil
param_.InputTo = param.In
if param_.IsObject {
param_.Type = param.Schema.Ref.GetPointer().String()[13:]
param_.Example = param.Schema.Example
}
item.Params = append(item.Params, param_)
}
// convert the operation response types into
// our internal format so that it is easier to
// work with in the template.
for code, resp := range op.Responses.StatusCodeResponses {
result := Result{}
result.Desc = resp.Description
result.Status = code
result.IsObject = resp.Schema != nil
if result.IsObject {
result.IsArray = resp.Schema.Items != nil
name := resp.Schema.Ref.GetPointer().String()
if len(name) != 0 {
def, _ := swag.Definitions[name[13:]]
result.Example = def.Example
}
}
if result.IsArray {
name := resp.Schema.Items.Schema.Ref.GetPointer().String()
def, _ := swag.Definitions[name[13:]]
result.Example = def.Example
}
item.Results = append(item.Results, result)
}
sort.Sort(ByCode(item.Results))
tag_.Ops = append(tag_.Ops, item)
}
}
sort.Sort(ByPath(tag_.Ops))
swag_.Tags = append(swag_.Tags, tag_)
}
return swag_
}
// hasTag is a helper function that returns true if
// an operation has the specified tag label.
func hasTag(want string, in []string) bool {
for _, got := range in {
if got == want {
return true
}
}
return false
}
// getMethod is a helper function that returns the http
// method for the specified operation in a path.
func getMethod(op *spec.Operation, path spec.PathItem) string {
switch {
case op == path.Get:
return "GET"
case op == path.Put:
return "PUT"
case op == path.Patch:
return "PATCH"
case op == path.Post:
return "POST"
case op == path.Delete:
return "DELETE"
}
return ""
}
// ByCode helps sort a list of results by status code
type ByCode []Result
func (a ByCode) Len() int { return len(a) }
func (a ByCode) Swap(i, j int) { a[i], a[j] = a[j], a[i] }
func (a ByCode) Less(i, j int) bool { return a[i].Status < a[j].Status }
// ByPath helps sort a list of endpoints by path
type ByPath []Operation
func (a ByPath) Len() int { return len(a) }
func (a ByPath) Swap(i, j int) { a[i], a[j] = a[j], a[i] }
func (a ByPath) Less(i, j int) bool { return a[i].Path < a[j].Path }

174
contrib/generate-docs.go
View file

@ -1,174 +0,0 @@
// +build ignore
// This program generates converts our markdown
// documentation to an html website.
package main
import (
"bytes"
"flag"
"html/template"
"io/ioutil"
"log"
"os"
"path/filepath"
"strings"
"github.com/PuerkitoBio/goquery"
"github.com/eknkc/amber"
"github.com/russross/blackfriday"
)
var (
input = flag.String("input", "docs/README.md", "path to site index")
output = flag.String("output", "_site/", "path to outpute website")
html = flag.String("template", "", "path to documentation template")
name = flag.String("name", "", "name of the site")
)
func main() {
flag.Parse()
// read the markdown file into a document element.
document, err := toDocument(*input)
if err != nil {
log.Fatalf("Error opening %s. %s", *input, err)
}
// we assume this file is the sitemap, so we'll look
// for the first ul element, and assume that contains
// the site hierarchy.
sitemap := document.Find("ul").First()
site := Site{}
site.Name = *name
site.base = filepath.Dir(*input)
// for each link in the sitemap we should attempt to
// read the markdown file and add to our list of pages
// to generate.
sitemap.Find("li > a").EachWithBreak(func(i int, s *goquery.Selection) bool {
page, err := toPage(&site, s)
if err != nil {
log.Fatalf("Error following link %s. %s", s.Text(), err)
}
if page != nil {
site.Pages = append(site.Pages, page)
}
return true
})
site.Nav = &Nav{}
site.Nav.elem = sitemap
site.Nav.html, err = sitemap.Html()
if err != nil {
log.Fatal(err)
}
// compiles our template which is in amber/jade format
templ := amber.MustCompileFile(*html, amber.DefaultOptions)
// for each page in the sitemap we generate a
// corresponding html file using the above template.
for _, page := range site.Pages {
path := filepath.Join(*output, page.Href)
f, err := os.Create(path)
if err != nil {
log.Fatalf("Error creating file %s. %s", path, err)
}
defer f.Close()
// correctly make the active page in the
// navigation html snippet
site.Nav.elem.Find("li > a").EachWithBreak(func(i int, s *goquery.Selection) bool {
href, _ := s.Attr("href")
if href == page.Href {
s.Parent().AddClass("active")
} else {
s.Parent().RemoveClass("active")
}
return true
})
site.Nav.html, _ = site.Nav.elem.Html()
data := map[string]interface{}{
"Site": site,
"Page": page,
}
err = templ.Execute(f, &data)
if err != nil {
log.Fatalf("Error generating template %s. %s", path, err)
}
}
}
type Site struct {
Nav *Nav
Pages []*Page
Name string
base string
}
type Nav struct {
html string
elem *goquery.Selection
}
func (n *Nav) HTML() template.HTML {
return template.HTML(n.html)
}
type Page struct {
Name string
Href string
html string
}
func (p *Page) HTML() template.HTML {
return template.HTML(p.html)
}
// toDocument is a helper function that parses a
// markdown file, converts to html markup, and returns
// a document element.
func toDocument(filename string) (*goquery.Document, error) {
raw, err := ioutil.ReadFile(filename)
if err != nil {
return nil, err
}
raw = blackfriday.MarkdownCommon(raw)
buf := bytes.NewBuffer(raw)
return goquery.NewDocumentFromReader(buf)
}
// toPage is a helper function that accepts an anchor
// tag referencing a markdown file, parsing the markdown
// file and returning a page to be included in our docs.
func toPage(site *Site, el *goquery.Selection) (*Page, error) {
// follow the link to see if this is a page
// that should be added to our documentation.
href, ok := el.Attr("href")
if !ok || href == "#" {
return nil, nil
}
// read the markdown file, convert to html and
// read into a dom element.
doc, err := toDocument(filepath.Join(site.base, href))
if err != nil {
return nil, err
}
// convert the extension from markdown to
// html, in preparation for type conversion.
href = strings.Replace(href, ".md", ".html", -1)
el.SetAttr("href", href)
page := &Page{}
page.Href = href
page.html, err = doc.Html()
return page, err
}

11
docs/build/README.md vendored
View file

@ -1,11 +0,0 @@
* [Overview](index.md)
* [Variables](env.md)
* [Secrets](secrets.md)
* [Cache](cache.md)
* [Clone](clone.md)
* [Build](build.md)
* [Services](services.md)
* [Publish](publish.md)
* [Deploy](deploy.md)
* [Notify](notify.md)
* [Matrix](matrix.md)

0
docs/build/badges.md vendored
View file

52
docs/build/build.md vendored
View file

@ -1,52 +0,0 @@
# Build
Drone uses the `build` section of the `.drone.yml` to describe your Docker build environment and your build and test instructions. The following is an example build definition:
```yaml
build:
image: golang
environment:
- GOBIN=/drone/bin
commands:
- go get
- go build
- go test
```
## Build options
The build configuration options:
* `image` - any valid Docker image name
* `pull` - if true, will always attempt to pull the latest image
* `environment` - list of environment variables, declared in `name=value` format
* `privileged` - if true, runs the container with extended privileges [1]
* `volumes` - list of bind mounted volumes on the host machine [1]
* `net` - sets the container [network mode](https://docs.docker.com/articles/networking/#container-networking) [1]
* `extra_hosts` - list of hostname mappings added to `/etc/hosts`
* `commands` - list of build commands
[1] Some build options are disabled for security reasons, including `volumes`, `privileged` and `net`. To enable these options, a system administrator must white-list your repository as trusted. This can be done via the repository settings screen.
## Build image
The `image` attribute supports any valid Docker image name:
```yaml
# Docker library image
image: golang
# Docker library image, with tag
image: golang:1.4
# Docker image, full name, with tag
image: library/golang:1.4
# fully qualified Docker image URI, with tag
image: index.docker.io/library/golang:1.4
```
## Skipping builds
Skip a build by including any combination of `ci` and `skip` wrapped in square brackets
in your commit message. Examples: `[skip CI]` `[ci skip]`

30
docs/build/cache.md vendored
View file

@ -1,30 +0,0 @@
# Caching
> This feature is still considered experimental
Drone allows you to cache directories within the build workspace (`/drone`). When a build successfully completes, the named directories are gzipped and stored on the host machine. When a new build starts, the named directories are restored from the gzipped files. This can be used to improve the performance of your builds.
Below is an example `.drone.yml` configured to cache the `.git` and the `node_modules` directory:
```yaml
cache:
mount:
- node_modules
- .git
```
## Branches and Matrix
Drone keeps a separate cache for each Branch and Matrix combination. Let's say, for example, you are using matrix builds to test `node 0.11.x` and `node 0.12.x` and you are caching `node_modules`. Drone will separately cache `node_modules` for each version of node.
## Pull Requests
Pull requests have read-only access to the cache. This means pull requests are not permitted to re-build the cache. This is done for security and stability purposes, to prevent a pull request from corrupting your cache.
## Deleting the Cache
There is currently no mechanism to automatically delete or flush the cache. This must be done manually, on each worker node. The cache is located in `/var/lib/drone/cache/`.
## Distributed Cache
This is outside the scope of Drone. You may, for example, use a distributed filesystem such as `ceph` or `gluster` mounted to `/var/lib/drone/cache/` to share the cache across nodes.

36
docs/build/clone.md vendored
View file

@ -1,36 +0,0 @@
# Clone
Drone automatically clones your repository and submodules at the start of your build. No configuration is required. You can, however, use the `clone` section of the `.drone.yml` to customize this behavior as needed.
## Clone Options
The custom clone options are:
* `depth` - creates a shallow clone with truncated history
* `recursive` - recursively clones git submodules
* `path` - relative path inside `/drone/src` where the repository is cloned
This is an example yaml configuration:
```yaml
clone:
depth: 50
recursive: true
path: github.com/drone/drone
```
Which results in the following command:
```
git clone --depth=50 --recusive=true \
https://github.com/drone/drone.git \
/drone/src/github.com/drone/drone
```
## Clone Private Repos
Cloning a private repository requires authentication to the remote system. Drone prefers `git+https` and `netrc` to authenticate, but will fallback to `git+ssh` and deploy keys if not supported.
Drone prefers `git+https` for authentication because it allows you to clone multiple private repositories. This is helpful when you have git submodules or third party dependencies you need to download (via `go get` or `npm install` or others) that are sourced from a private repository.
Drone only injects the `netrc` and `id_rsa` files into your build environment if your repository is private, or running in private mode. We do this for security reasons to avoid leaking sensitive data.

47
docs/build/deploy.md vendored
View file

@ -1,47 +0,0 @@
# Deploy
Drone uses the `deploy` section of the `.drone.yml` to configure deployment steps. Drone does not have any built-in deployment capabilities. This functionality is outsourced to [plugins](http://addons.drone.io). See the [plugin marketplace](http://addons.drone.io) for a list of official plugins.
An example plugin that deploys to Heroku:
```yaml
deploy:
heroku:
app: pied_piper
token: f10e2821bbbea5
```
## Deploy conditions
Use the `when` attribute to limit deployments to a specific branch:
```yaml
deploy:
heroku:
when:
branch: master
# you can also do simple matching
google_appengine:
when:
branch: feature/*
```
Declare multiple `heroku` deployment steps:
```yaml
# deploy master to our production heroku environment
heroku:
app: app.com
when:
branch: master
# deploy to our staging heroku environment
heroku:
app: staging.app.com
when:
branch: stage
```

61
docs/build/env.md vendored
View file

@ -1,61 +0,0 @@
# Variables
Drone injects the following namespaced environment variables into every build:
* `DRONE=true`
* `DRONE_REPO` - repository name for the current build
* `DRONE_BRANCH` - branch name for the current build
* `DRONE_COMMIT` - git sha for the current build
* `DRONE_DIR` - working directory for the current build
* `DRONE_BUILD_NUMBER` - build number for the current build
* `DRONE_PULL_REQUEST` - pull request number fo the current build
* `DRONE_JOB_NUMBER` - job number for the current build
* `DRONE_TAG` - tag name for the current build
Drone also injects `CI_` prefixed variables for compatibility with other systems:
* `CI=true`
* `CI_NAME=drone`
* `CI_REPO` - repository name of the current build
* `CI_BRANCH` - branch name for the current build
* `CI_COMMIT` - git sha for the current build
* `CI_BUILD_NUMBER` - build number for the current build
* `CI_PULL_REQUEST` - pull request number fo the current build
* `CI_JOB_NUMBER` - job number for the current build
* `CI_BUILD_DIR` - working directory for the current build
* `CI_BUILD_URL` - url for the current build
* `CI_TAG` - tag name for the current build
## Substitution
A subset of variables may be substituted directly into the Yaml at runtime using the `$$` notation:
* `$$BUILD_NUMBER` build number for the current build
* `$$COMMIT` git sha for the current build, long format
* `$$BRANCH` git branch for the current build
* `$$BUILD_NUMBER` build number for the current build
* `$$TAG` tag name
This is useful when you need to dynamically configure your plugin based on the current build. For example, we can alter an artifact name to include the branch:
```
publish:
s3:
source: ./foo.tar.gz
target: ./foo-$$BRANCH.tar.gz
```
## Operations
A subset of bash string substitution operations are emulated:
* `$$param` parameter substitution
* `$${param}` parameter substitution (same as above)
* `"$$param"` parameter substitution with escaping
* `$${param:pos}` parameter substition with substring
* `$${param:pos:len}` parameter substition with substring
* `$${param=default}` parameter substition with default
* `$${param##prefix}` parameter substition with prefix removal
* `$${param%%suffix}` parameter substition with suffix removal
* `$${param/old/new}` parameter substition with find and replace

41
docs/build/index.md vendored
View file

@ -1,41 +0,0 @@
# Overview
In order to configure your build, you must include a `.drone.yml` file in the root of your repository. This section provides a brief overview of the `.drone.yml` configuration file format.
Example `.drone.yml` for a Go repository:
```yaml
build:
image: golang
commands:
- go get
- go build
- go test
```
A more comprehensive example with linked service containers, deployment plugins and notification plugins:
```yaml
build:
image: golang
commands:
- go get
- go build
- go test
compose:
cache:
image: redis
database:
image: mysql
deploy:
heroku:
app: pied_piper
when:
branch: master
notify:
slack:
channel: myteam
```

83
docs/build/matrix.md vendored
View file

@ -1,83 +0,0 @@
# Matrix Builds
Drone uses the `matrix` section of the `.drone.yml` to define the build matrix. Drone executes a build for each permutation in the matrix, allowing you to build and test a single commit against many configurations.
Below is an example `.drone.yml` that tests a single commit against multiple versions of Go and Redis, resulting in a total of 6 different build permutations:
```yaml
build:
image: golang:$$GO_VERSION
commands:
- go get
- go build
- go test
compose:
redis:
image: redis:$$REDIS_VERSION
matrix:
GO_VERSION:
- 1.4
- 1.3
REDIS_VERSION:
- 2.6
- 2.8
- 3.0
```
## Matrix Variables
Matrix variables are injected into the `.drone.yml` file using the `$$` syntax, performing a simple find / replace. Matrix variables are also injected into your build container as environment variables.
This is an example `.drone.yml` file before injecting the matrix parameters:
```yaml
build:
image: golang:$$GO_VERSION
commands:
- go get
- go build
- go test
compose:
redis:
image: redis:$$REDIS_VERSION
matrix:
GO_VERSION:
- 1.4
REDIS_VERSION:
- 3.0
```
And this is the `.drone.yml` file after injecting the matrix parameters:
```yaml
build:
image: golang:1.4
environment:
- GO_VERSION=1.4
- REDIS_VERSION=3.0
commands:
- go get
- go build
- go test
compose:
redis:
image: redis:3.0
```
## Matrix Deployments
Matrix builds execute the same `.drone.yml` multiple times, but with different parameters. This means that publish and deployment steps are executed multiple times as well, which is typically undesired. To restrict a publish or deployment step to a single permutation you can add the following condition:
```yaml
deploy:
heroku:
app: foo
when:
matrix:
GO_VERSION: 1.4
REDIS_VERSION: 3.0
```

34
docs/build/notify.md vendored
View file

@ -1,34 +0,0 @@
# Notify
Drone uses the `notify` section of the `.drone.yml` to configure notification steps. Drone does not have any built-in notification capabilities. This functionality is outsourced to [plugins](http://addons.drone.io). See the [plugin marketplace](http://addons.drone.io) for a list of official plugins.
An example configuration that sends a Slack notification on build completion:
```yaml
notify:
slack:
webhook_url: https://hooks.slack.com/services/f10e2821bbb/200352313bc
channel: dev
username: drone
```
## Notification conditions
Use the `when` attribute to limit execution to a specific branch:
```yaml
publish:
slack:
when:
branch: master
```
Or limit execution based on the build status. The below example will only send the notification when the build fails:
```yaml
publish:
slack:
when:
success: false
failure: true
```

39
docs/build/publish.md vendored
View file

@ -1,39 +0,0 @@
# Publish
Drone uses the `publish` section of the `.drone.yml` to configure publish steps. Drone does not have any built-in publish or artifact capabilities. This functionality is outsourced to [plugins](http://addons.drone.io). See the [plugin marketplace](http://addons.drone.io) for a list of official plugins.
An example configuration that builds a Docker image and publishes to the registry:
```yaml
publish:
docker:
username: kevinbacon
password: pa55word
email: kevin.bacon@mail.com
repo: foo/bar
tag: latest
file: Dockerfile
```
## Publish conditions
Use the `when` attribute to limit execution to a specific branch:
```yaml
publish:
docker:
when:
branch: master
# you can also do simple matching
bintray:
when:
branch: feature/*
# or only publish when a tag is pushed
docker:
when:
event: tag
```

79
docs/build/secrets.md vendored
View file

@ -1,79 +0,0 @@
# Secret Variables
> this feature is still considered experimental
Drone allows you to store secret variables in an encrypted `.drone.sec` file in the root of your repository. This is useful when your build requires sensitive information that should not be stored in plaintext in your `.drone.yml` file.
An example `.drone.sec` yaml file, prior to being encryped:
```yaml
checksum: f63561783e550ccd21663d13eaf6a4d252d84147
environment:
- HEROKU_TOKEN=pa$$word
```
To encrypt the above yaml file
* navigate to your repository settings
* click the section labeled secret variables
* enter the plaintext yaml string in the textarea
* click the encrypt button
An encrypted string is returned to the browser. This string should be copied and pasted into a `.drone.sec` file in the root of your repository, alongside your `.drone.yml` file.
## Environment
The `environment` section of the `.drone.sec` file is a list of secret variables that get injected into your `.drone.yml` file at runtime using the `$$` notation. Secret variables are not injected as environment variables. Instead, we use a simple find and replace algorithm.
An example `.drone.yml` expecting the `HEROKU_TOKEN` private variable:
```yaml
build:
image: golang
commands:
- go get
- go build
- go test
deploy:
heroku:
app: pied_piper
token: $$HEROKU_TOKEN
```
## Substitution
A subset of bash string substitution operations are emulated:
* `$$param` parameter substitution
* `$${param}` parameter substitution (same as above)
* `"$$param"` parameter substitution with escaping
* `$${param:pos}` parameter substition with substring
* `$${param:pos:len}` parameter substition with substring
* `$${param=default}` parameter substition with default
* `$${param##prefix}` parameter substition with prefix removal
* `$${param%%suffix}` parameter substition with suffix removal
* `$${param/old/new}` parameter substition with find and replace
## Pull Requests
Secret variables are **not** injected into to the build section of the `.drone.yml` if your repository is **public** and the build is a **pull request**. This is for security purposes to prevent a malicious pull request from leaking your secrets.
Please note that you may still want secrets available to plugins when building a pull request. This is possible if you include a checksum of the `.drone.yml` file in your `.drone.sec` file.
## Checksum
The `checksum` field in the `.drone.sec` is a sha of your `.drone.yml` file. It is optional, but highly recommended. The `checksum` is used to verify the integrity of your `.drone.yml` file. If the checksum does not match, secret variables are not injected into your Yaml.
Generate a checksum on OSX or Linux:
```
$ shasum -a 256 .drone.yml
f63561783e550ccd21663d13eaf6a4d252d84147 .drone.yml
```
Generate a checksum on Windows with powershell:
```
$ (Get-FileHash .\.drone.yml -Algorithm SHA256).Hash.ToLower()
```

0
docs/build/selenium.md vendored
View file

42
docs/build/services.md vendored
View file

@ -1,42 +0,0 @@
# Services
Drone uses the `compose` section of the `.drone.yml` to specify supporting containers (ie service containers) that should be started and linked to your build container. The `compose` section of the `.drone.yml` is modeled after `docker-compose`:
```
compose:
[container_name:]
image: [image_name]
[options]
```
Example configuration that composes a Postgres and Redis container:
```yaml
compose:
cache:
image: redis
database:
image: postgres
environment:
- POSTGRES_USER=postgres
- POSTGRES_PASSWORD=mysecretpassword
```
## Service networking
Service containers are available at the `localhost` or `127.0.0.1` address.
Drone deviates from the default Docker compose networking model to mirror a traditional development environment, where services are typically accessed at `localhost` or `127.0.0.1`. To achieve this, we create a per-build network where all containers share the same network and IP address.
## Service options
The service container configuration options:
* `image` - any valid Docker image name
* `pull` - if true, will always attempt to pull the latest image
* `environment` - list of environment variables, declared in `name=value` format
* `privileged` - if true, runs the container with extended privileges [1]
* `volumes` - list of bind mounted volumes on the host machine [1]
* `net` - sets the container [network mode](https://docs.docker.com/articles/networking/#container-networking) [1]
[1] Some build options are disabled for security reasons, including `volumes`, `privileged` and `net`. To enable these options, a system administrator must white-list your repository as trusted. This can be done via the repository settings screen.

4
docs/cli/README.md
View file

@ -1,4 +0,0 @@
* [Install](index.md)
* [Local Builds](builds.md)
* [Encrypt Secrets](secrets.md)
* [Add Machines](machines.md)

35
docs/cli/builds.md
View file

@ -1,35 +0,0 @@
# Local Builds
The `exec` command lets you run a build on your personal machine (ie your laptop). It does not involve the Drone server in any way. This is very useful for local testing and troubleshooting.
## Instructions
The `drone exec` command should be executed from the root of your repository, where the `.drone.yml` file is located:
```
cd octocat/hello-world
drone exec
```
This only executes a `build` step. It does not execute `clone`, `publish`, `deploy`, or `notify` steps, nor will it decrypt your `.drone.sec` file.
## Arguments
The `exec` command accepts the following arguments:
* `DOCKER_HOST` - docker deamon address. defaults to `unix:///var/run/docker.sock`
* `DOCKER_TLS_VERIFY` - docker daemon supports tlsverify
* `DOCKER_CERT_PATH` - docker certificate directory
## Boot2Docker
You may use the `drone exec` command with boot2docker as long as your code exists within your `$HOME` directory. This is because boot2docker mounts your home directory into the virtualbox instance giving the Docker daemon access to your local files.
## Known Issues
Attempting to cancel (`ctrl+C`) a running build will leave behind orphan containers. This is a known issue and we are planning a fix.
## Limitations
You cannot use `drone exec` with a remote Docker instance. Your local codebase is shared via a volume with the Docker daemon, which is not possible when communicating with a remote Docker host on a different machine.

50
docs/cli/index.md
View file

@ -1,50 +0,0 @@
# Install
> This is an early preview of the command line utility. Contributors wanted.
Drone provides a simple command line utility that allows you interact with the Drone server from the command line. This section describes the setup and installation process.
## System Requirements
This tool requires Docker 1.6 or higher. If you are using Windows or Mac we recommend installing the [Docker Toolbox](https://www.docker.com/docker-toolbox).
## Linux
Download and install the x64 linux binary:
```
curl http://downloads.drone.io/drone-cli/drone_linux_amd64.tar.gz | tar zx
sudo install -t /usr/local/bin drone
```
## OSX
Download and install using Homebrew:
```
brew tap drone/drone
brew install drone
```
Or manually download and install the binary:
```
curl http://downloads.drone.io/drone-cli/drone_darwin_amd64.tar.gz | tar zx
sudo cp drone /usr/local/bin
```
## Setup
In order to communicate with the Drone server you must provide the server url:
```
export DRONE_SERVER=<http://>
```
In order to authorize communications you must also provide your access token:
```
export DRONE_TOKEN=<token>
```
You can retrieve your access token from the user profile screen in Drone.

46
docs/cli/machines.md
View file

@ -1,46 +0,0 @@
# Machine Management
The `drone node create` command lets your register new remote servers with Drone. This command should be used in conjunction with [docker-machine](https://github.com/docker/machine). Note that you can alternatively register and manage servers in the UI.
## Environment Variables
The `drone node create` command expects the following environment variables:
* `DOCKER_HOST` - docker deamon address
* `DOCKER_TLS_VERIFY` - docker daemon supports tlsverify
* `DOCKER_CERT_PATH` - docker certificate directory
## Instructions
Create or configure a new server using `docker-machine`:
```
docker-machine create \
--digitalocean-size 2gb \
--driver digitalocean \
--digitalocean-access-token <token> \
my-drone-worker
```
This writes setup instructions to the console:
```
export DOCKER_TLS_VERIFY="1"
export DOCKER_HOST="tcp://123.456.789.10:2376"
export DOCKER_CERT_PATH="/home/octocat/.docker/machine/machines/my-drone-worker"
export DOCKER_MACHINE_NAME="my-drone-worker"
# Run this command to configure your shell:
# eval "$(docker-machine env my-drone-worker)"
```
Run the following command (from the above output) to configure your shell:
```
eval "$(docker-machine env my-drone-worker)"
```
Register the newly created or configured machine with Drone. Once registered, Drone will immediately begin sending builds to the server.
```
drone node create
```

3
docs/cli/overview.md
View file

@ -1,3 +0,0 @@
# Overview
> Coming Soon

45
docs/cli/secrets.md
View file

@ -1,45 +0,0 @@
# Encrypt Secrets
The `secure` command lets your create a signed and encrypted `.drone.sec` file. The `.drone.sec` file is decrypted at runtime and will inject your secrets into your `.drone.yml` file.
## Usage
Create a plaintext `.drone.sec.yml` file that contains your secret variables:
```
environment:
- PASSWORD=foo
```
Encrypt and generate the `.drone.sec` file:
```
drone secure --repo octocat/hello-world
```
Commit the encrypted `.drone.sec` file to your repository.
Note the `drone secure` command will automatically calculate the shasum of your yaml file and store in the `.drone.sec` file. This prevent secrets from being injected into the build if the Yaml changes.
## Arguments
The `secure` command accepts the following arguments:
* `--in` secrets in plain text yaml. defaults to `.drone.sec.yml`
* `--out` encrypted secret file. defaults to `.drone.sec`
* `--yaml` location of your `.drone.yml` file. defaults to `.drone.yml`
* `--repo` name of your repository **required**
## Shared Secrets
You cannot re-use the same `.drone.sec` for multiple repositories. You can, however, use the same plaintext secret file for multiple repositories.
```
cd octocat/hello-world
drone secure --in $HOME/.drone.sec.yml --repo octocat/hello-world
cd octocat/Spoon-Knife
drone secure --in $HOME/.drone.sec.yml --repo octocat/Spoon-Knife
```

3
docs/plugin/README.md
View file

@ -1,3 +0,0 @@
* [Overview](index.md)
* [Example](example.md)
* [Publish](publish.md)

156
docs/plugin/example.md
View file

@ -1,156 +0,0 @@
# Plugin Tutorial
We're going to create a plugin that allows Drone to send a webhook when a build completes. The webhook will send an http POST request to one or more URLs with the build details, encoded in JSON format.
## Plugin Yaml
Many plugins call for some options the user can set, which can be specified in the `.drone.yml` file. This is an example configuration for our `webhook` plugin:
```yaml
---
notify:
webhook:
image: bradrydzewski/webhook
urls:
- http://foo.com/post/to/this/url
```
The `image` attribute refers to the name of our plugin's Docker image. The `urls` attribute is a custom option allowing the user to define the list of webhook urls.
## Plugin executable
The next step is to write the code for our plugin. Our plugin will need access to information about the running build, and it will need its configuration options. Luckily, the build and repository details are passed to the program as a JSON encoded string over `arg[1]`.
The Drone team created the `drone-plugin-go` library to simplify plugin development, and we'll use this library to create our webhook plugin. First, we'll need to download the library using `go get` and import into our `main.go` file:
```go
import (
"github.com/drone/drone-plugin-go"
)
```
Next we'll need to read and unmarshal the repository and build detail from `arg[1]`. Our plugin package provides simple helper functions, modeled after the `flag` package, to fetch this data. We'll also need to read and unmarshal our plugin options. Plugin options are passed as the `vargs` paramter.
```go
func main() {
var repo = plugin.Repo{}
var build = plugin.Build{}
var vargs = struct {
Urls []string `json:"urls"`
}{}
plugin.Param("repo", &repo)
plugin.Param("build", &build)
plugin.Param("vargs", &vargs)
plugin.Parse()
// post build and repo data to webhook urls
}
```
Once we've parsed the build and repository details, and the webhook urls, we are ready to make the http requests. First, we'll need to construct our payload and marshal to JSON:
```go
data := struct{
Repo plugin.Repo `json:"repo"`
Build plugin.Build `json:"build"`
}{repo, build}
payload, _ := json.Marshal(&data)
```
And finally, for each URL in the list, we post the JSON payload:
```go
for _, url := range vargs.Urls {
resp, _ := http.Post(url, "application/json", bytes.NewBuffer(payload))
resp.Body.Close()
}
```
## Plugin image
Since plugins are distributed as Docker images, we'll need to create a `Dockerfile` for our plugin:
```dockerfile
FROM gliderlabs/alpine:3.1
RUN apk-install ca-certificates
ADD drone-webhook /bin/
ENTRYPOINT ["/bin/drone-webhook"]
```
We recommend using the `gliderlabs/alpine` base image due to its compact size. Plugins are downloaded automatically during build execution, therefore, smaller images and faster download times provide a better overall user experience.
## Plugin testing
We can quickly test our plugin from the command line, with dummy data, to make sure everything works. Note that you can send the JSON string over `stdin` instead of `arg[1]` only when testing:
```bash
go run main.go <<EOF
{
"repo": {
"owner": "octocat",
"name": "hello-world",
"full_name": "octocat/hello-world"
},
"build": {
"number": 1,
"status": "success"
},
"vargs": {
"urls": [ "http://foo.com/post/to/this/url" ]
}
}
EOF
```
## Complete example
Here is the complete Go program:
```go
import (
"bytes"
"encoding/json"
"net/http"
"github.com/drone/drone-plugin-go"
)
func main() {
var repo = plugin.Repo{}
var build = plugin.Build{}
var vargs = struct {
Urls []string `json:"urls"`
}{}
plugin.Param("repo", &repo)
plugin.Param("build", &build)
plugin.Param("vargs", &vargs)
plugin.Parse()
// data structure
data := struct{
Repo plugin.Repo `json:"repo"`
Build plugin.Build `json:"build"`
}{repo, build}
// json payload that will be posted
payload, _ := json.Marshal(&data)
// post payload to each url
for _, url := range vargs.Urls {
resp, _ := http.Post(url, "application/json", bytes.NewBuffer(payload))
resp.Body.Close()
}
}
```
And the Dockerfile:
```dockerfile
FROM gliderlabs/alpine:3.1
RUN apk-install ca-certificates
ADD drone-webhook /bin/
ENTRYPOINT ["/bin/drone-webhook"]
```

66
docs/plugin/index.md
View file

@ -1,66 +0,0 @@
# Overview
Drone has a robust plugin model that allows you to extend the platform to meet your unique project needs. This documentation describes the Drone plugin architecture and will help you create your own custom plugins. If you are searching for existing plugins please see the [plugin marketplace](http://addons.drone.io).
## How Plugins Work
Plugins are simply Docker containers that attach to your build at runtime and perform custom operations. These operations may include deploying code, publishing artifacts and sending notifications.
Plugins are declared in the `.drone.yml` file. When Drone encounters a plugin it attempts to download from the registry (if not already downloaded) and then execute. This is an example of the [slack plugin](https://github.com/drone-plugins/drone-slack) configuration:
```yaml
---
notify:
slack:
image: plugins/slack
webhook_url: https://hooks.slack.com/services/...
username: captain_freedom
channel: ics
```
Plugins receive plugin configuration data, repository and build data as an encoded JSON string. The plugin can use this data when executing its task. For example, the [slack plugin](https://github.com/drone-plugins/drone-slack) uses the build and repository details to format and send a message to a channel.
Plugins also have access to the `/drone` volume, which is shared across all containers, including the build container. The repository is cloned to a subdirectory of `/drone/src`, which means plugins have access to your source code as well as any generated assets (binary files, reports, etc). For example, the [heroku plugin](https://github.com/drone-plugins/drone-heroku) accesses your source directory and executes `git push heroku master` to deploy your code.
## Plugin Input
Plugins receive build details via `arg[1]` as a JSON encoded string. The payload includes the following data structures:
* `repo` JSON representation of the repository
* `build` JSON representation of the build, including commit and pull request
* `vargs` JSON representation of the plugin configuration, as defined in the `.drone.yml`
Drone provides a simple [plugin library](https://github.com/drone/drone-plugin-go) that helps read and unmarshal the input parameters:
```go
func main() {
var repo = plugin.Repo{}
var build = plugin.Build{}
var vargs = struct {
Webhook string `json:"webhook_url"`
Username string `json:"username"`
Channel string `json:"channel"`
}{}
plugin.Param("repo", &repo)
plugin.Param("build", &build)
plugin.Param("vargs", &vargs)
plugin.Parse()
// send slack notification
}
```
## Plugin Output
Plugins cannot send structured data back to Drone. Plugins can, however, write information to stdout so that it appears in the logs. Plugins can fail a build by exiting with a non-zero status code.
You may be asking yourself "how do I send reports or metrics back to Drone" or "how do I generate and store artificats in Drone"? The answer is that you cannot. Instead, you should use plugins to generate reports and send to third party services (like Coveralls) or generate and upload artifacts to third party storage services (like Bintray or S3).
## Plugin Reference
These are existing plugins that you can reference when building your own:
* [Slack](https://github.com/drone-plugins/drone-slack) - publish messages to a Slack channel when your build finishes
* [Heroku](https://github.com/drone-plugins/drone-heroku) - deploy your application to Heroku
* [Docker](https://github.com/drone-plugins/drone-docker) - build and publish your Docker image to a registry

44
docs/plugin/publish.md
View file

@ -1,44 +0,0 @@
# Publishing Plugins
Plugins must be published to a Docker registry in order for Drone to download and execute at runtime. You can publish to the official registry (at [index.docker.io](https://index.docker.io)) or to a private registry.
## Plugin marketplace
Official plugins are published to [index.docker.io/u/plugins](https://index.docker.io/u/plugins/) and are listed in the [plugin marketplace](http://addons.drone.io). If you would like to submit your plugin to the marketplace, as an officially supported Drone plugin, it must meet the following criteria:
* Plugin is useful to the broader community
* Plugin is documented
* Plugin is written in Go [1]
* Plugin has manifest file
* Plugin uses Apache2 license
* Plugin uses `gliderlabs/apline` base image (unless technical limitations prohibit)
[1] Although plugins can be written in any language, official plugins must be written in Go. The core Drone team consists of primarily Go developers and we simply lack the expertise and bandwidth to support multiple stacks. This may change in the future (remember, this is still a young project) but for now this remains a requirement.
## Plugin manifest
The plugin manifest, a subsection of the `.drone.yml` file, contains important information about your plugin:
* `name` - display name of the plugin
* `desc` - brief description of the plugin
* `type` - type of plugin. Possible values are clone, publish, deploy, notify
* `image` - image repository in the Docker registry
Here is the [example manifest](https://github.com/drone-plugins/drone-slack/blob/master/.drone.yml) for the slack plugin:
```yaml
---
plugin:
name: Slack
desc: Sends build status notifications to your Slack channel.
type: notify
image: plugins/drone-slack
labels:
- chat
- messaging
```
## Plugin documentation
The plugin documentation is stored in the `./DOCS.md` file in the root of the repository. This file is used to auto-generate the documentation displayed in the [plugin marketplace](http://addons.drone.io).

17
docs/setup/README.md
View file

@ -1,17 +0,0 @@
* Install
* [Install](index.md)
* [Upgrade](upgrade.md)
* [Plugins](plugins.md)
* Server
* [Server](server.md)
* [Proxy](proxy.md)
* [Nginx](nginx.md)
* Remotes
* [GitHub](github.md)
* [Bitbucket](bitbucket.md)
* [Gogs](gogs.md)
* [GitLab](gitlab.md)
* Database
* [SQLite](sqlite.md)
* [MySQL](mysql.md)
* [Postgres](postgres.md)

50
docs/setup/bitbucket.md
View file

@ -1,50 +0,0 @@
# Bitbucket
Drone comes with built-in support for Bitbucket. To enable Bitbucket you should configure the Bitbucket driver using the following environment variables:
```bash
REMOTE_DRIVER=bitbucket
REMOTE_CONFIG=https://bitbucket.org?client_id=${client_id}&client_secret=${client_secret}
```
## Bitbucket configuration
The following is the standard URI connection scheme:
```
scheme://host[?options]
```
The components of this string are:
* `scheme` server protocol `http` or `https`.
* `host` server address to connect to.
* `?options` connection specific options.
## Bitbucket options
This section lists all connection options used in the connection string format. Connection options are pairs in the following form: `name=value`. The value is always case sensitive. Separate options with the ampersand (i.e. &) character:
* `client_id` oauth client id for registered application.
* `client_secret` oauth client secret for registered application.
* `open=false` allows users to self-register. Defaults to false.
* `orgs=drone&orgs=docker` restricts access to these Bitbucket organizations. **Optional**
## Bitbucket registration
You must register your application with Bitbucket in order to generate a Client and Secret. Navigate to your account settings and choose OAuth from the menu, and click Add Consumer.
Please use `http://drone.mycompany.com/authorize` as the Authorization callback URL. You will also need to check the following permissions:
* Account:Email
* Account:Read
* Team Membership:Read
* Repositories:Read
* Webhooks:Read and Write
## Known Issues
This section details known issues and planned features:
* Pull Request support
* Mercurial support

91
docs/setup/docker.md
View file

@ -1,91 +0,0 @@
# Docker
Drone uses the local Docker daemon (at `unix:///var/run/docker.sock`) to execute your builds with 2x concurrency. This section describes how to customize your Docker configuration and concurrency settings using the `DOCKER_*` environment variables.
Configure a single Docker host (1x build concurrency):
```bash
DOCKER_HOST="unix:///var/run/docker.sock"
```
## Concurrency
Configure Drone to run multiple, concurrent builds by increasing the number of registered Docker hosts. Each `DOCKER_HOST_*` environment variable will increase concurrency by 1.
Configure multiple Docker hosts (4x build concurrency):
```bash
DOCKER_HOST_1="unix:///var/run/docker.sock"
DOCKER_HOST_2="unix:///var/run/docker.sock"
DOCKER_HOST_3="unix:///var/run/docker.sock"
DOCKER_HOST_4="unix:///var/run/docker.sock"
```
Configure a single, external Docker host (1x build concurrency):
```bash
DOCKER_HOST="tcp://1.2.3.4:2376"
DOCKER_CA="/path/to/ca.pem"
DOCKER_CERT="/path/to/cert.pem"
DOCKER_KEY="/path/to/key.pem"
```
Configure multiple, external Docker hosts (4x build concurrency using 2 remote servers):
```bash
DOCKER_HOST_1="tcp://1.2.3.4:2376"
DOCKER_HOST_2="tcp://1.2.3.4:2376"
DOCKER_HOST_3="tcp://4.3.2.1:2376"
DOCKER_HOST_4="tcp://4.3.2.1:2376"
DOCKER_CA="/path/to/ca.pem"
DOCKER_CERT="/path/to/cert.pem"
DOCKER_KEY="/path/to/key.pem"
```
## Remote Servers
Connecting to remote Docker servers requires TLS authentication for security reasons. You will therefore need to generate your own self-signed certificates. For convenience, we've created the following gist to help generate a certificate: https://gist.github.com/bradrydzewski/a6090115b3fecfc25280
This will generate the following files:
* ca.pem
* cert.pem
* key.pem
* server-cert.pem
* server-key.pem
Tell Drone where to find the `cert.pem` and `key.pem`:
```bash
DOCKER_CERT="/path/to/cert.pem"
DOCKER_KEY="/path/to/key.pem"
```
When running Drone inside Docker, you'll need to mount the volume containing the certificate:
```bash
docker run
--volume /path/to/cert.pem:/path/to/cert.pem \
--volume /path/to/key.pem:/path/to/key.pem \
```
Tell Docker where to find the certificate files. Install the certificates on every remote machine (in `/etc/ssl/docker/`) and update each Docker configuration file (at `/etc/init/drone-dart.conf`) accordingly:
```bash
# Use DOCKER_OPTS to modify the daemon startup options.
DOCKER_OPTS="--tlsverify --tlscacert=/etc/ssl/docker/ca.pem --tlscert=/etc/ssl/docker/server-cert.pem --tlskey=/etc/ssl/docker/server-key.pem -H=0.0.0.0:2376 -H unix:///var/run/docker.sock"
```
Verify that everything is configured correctly by connecting to a remote Docker server from our Drone server using the following command:
```bash
sudo docker \
--tls \
--tlscacert=/path/to/ca.pem \
--tlscert=/path/to/cert.pem \
--tlskey=/path/to/key.pem \
-H="1.2.3.4:2376" version
```

41
docs/setup/github.md
View file

@ -1,41 +0,0 @@
# GitHub
Drone comes with built-in support for GitHub and GitHub Enterprise. To enable GitHub you should configure the GitHub driver using the following environment variables:
```bash
REMOTE_DRIVER=github
REMOTE_CONFIG=https://github.com?client_id=${client_id}&client_secret=${client_secret}
```
## GitHub configuration
The following is the standard URI connection scheme:
```
scheme://host[:port][?options]
```
The components of this string are:
* `scheme` server protocol `http` or `https`.
* `host` server address to connect to. The default value is github.com if not specified.
* `:port` optional. The default value is :80 if not specified.
* `?options` connection specific options.
## GitHub options
This section lists all connection options used in the connection string format. Connection options are pairs in the following form: `name=value`. The value is always case sensitive. Separate options with the ampersand (i.e. &) character:
* `client_id` oauth client id for registered application.
* `client_secret` oauth client secret for registered application.
* `scope=repo,repo:status,user:email` oauth scopes.
* `open=false` allows users to self-register. Defaults to false..
* `orgs=drone&orgs=docker` restricts access to these GitHub organizations. **Optional**
* `private_mode=false` indicates GitHub Enterprise is running in private mode.
* `skip_verify=false` skip ca verification if self-signed certificate. Defaults to false.
## GitHub registration
You must register your application with GitHub in order to generate a Client and Secret. Navigate to your account settings and choose Applications from the menu, and click Register new application.
Please use `http://drone.mycompany.com/authorize` as the Authorization callback URL.

43
docs/setup/gitlab.md
View file

@ -1,43 +0,0 @@
# Gitlab
> GitLab support is experimental and unstable due to high variation in GitLab configurations and versions. We highly recommend using [Gogs](https://github.com/gogits/gogs) as an alternative to GitLab.
Drone comes with built-in support for GitLab version 8.0 and higher. To enable Gitlab you should configure the Gitlab driver using the following environment variables:
```bash
REMOTE_DRIVER=gitlab
REMOTE_CONFIG=https://gitlab.hooli.com?client_id=${client_id}&client_secret=${client_secret}
```
## Gitlab configuration
The following is the standard URI connection scheme:
```
scheme://host[:port][?options]
```
The components of this string are:
* `scheme` server protocol `http` or `https`.
* `host` server address to connect to. The default value is github.com if not specified.
* `:port` optional. The default value is :80 if not specified.
* `?options` connection specific options.
## GitLab options
This section lists all connection options used in the connection string format. Connection options are pairs in the following form: `name=value`. The value is always case sensitive. Separate options with the ampersand (i.e. &) character:
* `client_id` oauth client id for registered application
* `client_secret` oauth client secret for registered application
* `open=false` allows users to self-register. Defaults to false for security reasons.
* `orgs=drone&orgs=docker` restricts access to these GitLab organizations. **Optional**
* `skip_verify=false` skip ca verification if self-signed certificate. Defaults to false for security reasons.
* `hide_archives=false` hide projects archived in GitLab from the listing.
* `clone_mode=token` a strategy for clone authorization, by default use repo token, but can be changed to `oauth` ( This is not secure, because your user token, with full access to your gitlab account will be written to .netrc, and it can be read by all who have access to project builds )
## Gitlab registration
You must register your application with GitLab in order to generate a Client and Secret. Navigate to your account settings and choose Applications from the menu, and click New Application.
Please use `http://drone.mycompany.com/authorize` as the Authorization callback URL.

31
docs/setup/gogs.md
View file

@ -1,31 +0,0 @@
# Gogs
Drone comes with built-in support for Gogs version `0.6.16.1022` and higher. Pleasure ensure you are running the latest version of Gogs to avoid compatibility issues. To enable Gogs you should configure the Gogs driver using the following environment variables:
```bash
REMOTE_DRIVER=gogs
REMOTE_CONFIG=https://gogs.hooli.com?open=false
```
## Gogs configuration
The following is the standard URI connection scheme:
```
scheme://host[:port][/path][?options]
```
The components of this string are:
* `scheme` server protocol `http` or `https`.
* `host` server address to connect to. The default value is github.com if not specified.
* `:port` optional. The default value is :80 if not specified.
* `/path` optional. The default value is the root directory if not specified.
* `?options` connection specific options.
## Gogs options
This section lists all connection options used in the connection string format. Connection options are pairs in the following form: `name=value`. The value is always case sensitive. Separate options with the ampersand (i.e. &) character:
* `open=false` allows users to self-register. Defaults to false for security reasons.
* `skip_verify=false` skip ca verification if self-signed certificate. Defaults to false for security reasons.

54
docs/setup/index.md
View file

@ -1,54 +0,0 @@
# Installation
To quickly tryout Drone we have a [Docker image](https://registry.hub.docker.com/u/drone/drone/) that includes everything you need to get started. Simply run the commend below:
```
sudo docker pull drone/drone:0.4
```
And then run the container:
```
sudo docker run \
--volume /var/lib/drone:/var/lib/drone \
--volume /var/run/docker.sock:/var/run/docker.sock \
--env-file /etc/drone/dronerc \
--restart=always \
--publish=80:8000 \
--detach=true \
--name=drone \
drone/drone:0.4
```
Drone is now running (in the background) on `http://localhost:80`. Note that before running you should create the `--env-file` and add your Drone configuration (GitHub, Bitbucket, GitLab credentials, etc).
## Docker options
Here are some of the Docker options, explained:
* `--restart=always` starts Drone automatically during system init process
* `--publish=80:8000` runs Drone on port `80`
* `--detach=true` starts Drone in the background
* `--volume /var/lib/drone:/var/lib/drone` mounted volume to persist sqlite database
* `--volume /var/run/docker.sock:/var/run/docker.sock` mounted volume to access Docker and spawn builds
* `--env-file /etc/defaults/drone` loads an external file with environment variables. Used to configure Drone.
## Drone settings
Drone uses environment variables for runtime settings and configuration, such as GitHub, GitLab, plugins and more. These settings can be provided to Docker using an `--env-file` as seen above.
## Starting, Stopping, Logs
Commands to start, stop and restart Drone:
```
sudo docker start drone
sudo docker stop drone
sudo docker restart drone
```
And to view the Drone logs:
```
sudo docker logs drone
```

48
docs/setup/mysql.md
View file

@ -1,48 +0,0 @@
> mysql driver has known timeout issues. See [#257](https://github.com/go-sql-driver/mysql/issues/257).
# MySQL
Drone comes with support for MySQL as an alternate database engine. To enable MySQL, you should specify the following environment variables:
```bash
DATABASE_DRIVER="mysql"
DATABASE_CONFIG="root:pa55word@tcp(localhost:3306)/drone?parseTime=true"
```
## MySQL configuration
The following is the standard URI connection scheme:
```
[username[:password]@][protocol[(address)]]/dbname[?options]
```
The components of this string are:
* `username` optional. Use this username when connecting to the MySQL instance.
* `password` optional. Use this password when connecting to the MySQL instance.
* `protocol` server protocol to connect with.
* `address` server address to connect to.
* `dbname` name of the database to connect to
* `?options` connection specific options
This is an example connection string:
```
root:pa55word@tcp(localhost:3306)/drone?parseTime=true
```
Please note that `parseTime` is a **required** paramter.
## MySQL options
See the official [driver documentation](https://github.com/go-sql-driver/mysql#parameters) for a full list of driver options. Note that the `parseTime=true` is required.
## MySQL Database
Drone does not automatically create the database. You should use the command line utility or your preferred management console to create the database:
```bash
mysql -P 3306 --protocol=tcp -u root -e 'create database if not exists drone;'
```

24
docs/setup/nginx.md
View file

@ -1,24 +0,0 @@
# Nginx
Using a proxy server is **not necessary**. Drone serves most static content from a CDN and uses the Go standard library's high-performance net/http package to serve dynamic content.
If using Nginx to proxy traffic to Drone, please ensure you have version 1.3.13 or greater. You also need to configure nginx to write `X-Forwarded_*` headers:
```
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Host $http_host;
proxy_set_header Origin "";
proxy_pass http://127.0.0.1:8000;
proxy_redirect off;
proxy_http_version 1.1;
proxy_buffering off;
chunked_transfer_encoding off;
}
```
Our installation instructions recommend running Drone in a Docker container with port `:80` published. When behind a reverse proxy, you should run the Drone Docker container with `--publish=8000:8000`. This will publish Drone to port `:8000` allowing you to proxy from `:80`.

31
docs/setup/plugins.md
View file

@ -1,31 +0,0 @@
# Plugins
Plugins are Docker containers, executed during your build process. Plugins are downloaded automatically, on-demand as they are encountered in your `.drone.yml` file.
See the [plugin marketplace](http://addons.drone.io) for a full catalog of official plugins.
## Security
For security reasons you must whitelist plugins. The default whitelist includes the official Drone plugins hosted in the [Docker registry](https://registry.hub.docker.com/repos/plugins/). Customize your whitelist by setting the `PLUGIN_FILTER` environment variable. This is a space-separated list and includes glob matching capabilities.
Whitelist official Drone plugins
```
PLUGIN_FILTER=plugins/*
```
Whitelist official Drone plugins and registry user `octocat`
```
PLUGIN_FILTER=plugins/* octocat/*
```
Additionally, some plugins may require to be execute as a "privileged" container.
This mode is most common for plugins that are attempting to run docker in docker type behaviors (for example the plugins/docker requires this mode).
Drone will ship will a default pattern that will allow selected official Drone plugins to run in an privileged mode.
This whitelist can be customized by setting the `ESCALATE_FILTER` environment variable.
This is a space-separated list and includes glob matching capabilities.
```
ESCALATE_FILTER=plugins/drone-docker plugins/drone-ecr plugins/drone-gcr
```

42
docs/setup/postgres.md
View file

@ -1,42 +0,0 @@
# Postgres
Drone comes with support for Postgres as an alternate database engine. To enable Postgres, you should specify the following environment variables:
```
DATABASE_DRIVER=postgres
DATABASE_CONFIG=postgres://root:pa55word@127.0.0.1:5432/postgres
```
## Postgres configuration
The following is the standard URI connection scheme:
```
postgres://[username:password@]host[:port]/[dbname][?options]
```
The components of this string are:
* `postgres://` required prefix
* `username:password@` optional. Use these credentials when connecting to the Postgres instance.
* `host` server address to connect to. It may be a hostname, IP address, or UNIX domain socket.
* `:port` optional. The default value is `:5432` if not specified.
* `dbname` name of the database to connect to
* `?options` connection specific options
This is an example connection string:
```
postgres://root:pa55word@127.0.0.1:5432/postgres
```
## Postgres options
This section lists all connection options used in the connection string format. Connection options are pairs in the following form: `name=value`. The value is always case sensitive. Separate options with the ampersand (i.e. &) character:
* `sslmode` initiates the connection with TLS/SSL (disable, require, verify-ca, verify-full)
* `connect_timeout` maximum wait for connection, in seconds.
* `sslcert` cert file location. The file must contain PEM encoded data.
* `sslkey` key file location. The file must contain PEM encoded data.
* `sslrootcert` location of the root certificate file. The file must contain PEM encoded data.

31
docs/setup/proxy.md
View file

@ -1,31 +0,0 @@
# Proxy
This document provides high-level instructions for configuring Drone to work with a corporate proxy server.
## Http Proxy
The HTTP_PROXY environment variable holds the hostname or IP address of your proxy server. You can specify the HTTP_PROXY variables in your `/etc/drone/dronerc` file or as an envronment variable.
```
HTTPS_PROXY=https://proxy.example.com
HTTP_PROXY=http://proxy.example.com
```
These variables are propogated throughout your build environment, including build and plugin containers. To verify the environment variables are being set in your build container you can add the `env` command to your build script.
We also recommend you provide both uppercase and lowercase environment variables. We've found that certain common unix tools are case-sensitive:
```
HTTP_PROXY=http://proxy.example.com
http_proxy=http://proxy.example.com
```
## No Proxy
The `NO_PROXY` variable should contain a comma-separated list of domain extensions the proxy should not be used for. This typically includes resources inside your network, such as your GitHub Enterprise server.
```
NO_PROXY=.example.com, *.docker.example.com
```
You may also need to add your Docker daemon hostnames to the above list.

39
docs/setup/server.md
View file

@ -1,39 +0,0 @@
# Server
Drone uses the `net/http` package in the Go standard library for high-performance `http` request processing. This section describes how to customize the default server configuration. This section is completely **optional**.
## Server Settings
This section lists all environment variables used to configure the server.
* `SERVER_ADDR` server address and port. Defaults to `:8000`
* `SERVER_KEY` ssl certificate key (key.pem)
* `SERVER_CERT` ssl certificate (cert.pem)
This example changes the default port to `:80`:
```bash
SERVER_ADDR=:80
```
## Server SSL
Drone uses the `ListenAndServeTLS` function in the Go standard library to accept `https` connections. If you experience any issues configuring `https` please contact us on [gitter](https://gitter.im/drone/drone). Please do not log an issue saying `https` is broken in Drone.
This example accepts `HTTPS` connections:
```bash
SERVER_ADDR=:443
SERVER_KEY=/path/to/key.pem
SERVER_CERT=/path/to/cert.pem
```
> When your certificate is signed by an authority, the certificate should be the concatenation of the server's certificate followed by the CA certificate.
When running Drone inside Docker, you'll need to mount a volume containing the certificate:
```bash
docker run
--volume /path/to/cert.pem:/path/to/cert.pem \
--volume /path/to/key.pem:/path/to/key.pem \
```

26
docs/setup/sqlite.md
View file

@ -1,26 +0,0 @@
# SQLite
Drone uses SQLite as the default database with zero configuration required. In order to customize the SQLite database configuration you should specify the following environment variables:
```bash
DATABASE_DRIVER=sqlite3
DATABASE_CONFIG=/var/lib/drone/drone.sqlite
```
## Sqlite3 configuration
The following is the standard URI connection scheme:
```
file:path[?options]
```
The components of the datasource connection string are:
* `file:` URI prefix to identify database files.
* `path` local path to the database file. The default value is `/var/lib/drone/drone.sqlite`.
* `?options` connection specific options. **not recommended**
## Sqlite3 options
See the official [driver documentation](https://www.sqlite.org/uri.html#coreqp) for a full list of driver options.

43
docs/setup/ubuntu.md
View file

@ -1,43 +0,0 @@
# Ubuntu
These are the instructions for running Drone on Ubuntu . We recommend using Ubuntu 14.04, the latest stable distribution. We also highly recommend using AUFS as the default file system driver for Docker.
## System Requirements
The default Drone installation uses a SQLite3 database for persistence. Please ensure you have libsqlite3-dev installed:
```
sudo apt-get update
sudo apt-get install libsqlite3-dev
```
The default Drone installation also assumes Docker is installed locally on the host machine. To install Docker on Ubuntu please see the official [installation guide](https://docs.docker.com/installation/ubuntulinux/).
## Installation
Once the environment is prepared you can install Drone from a debian file:
```
wget downloads.drone.io/0.4.0/drone.deb
sudo dpkg --install drone.deb
```
## Settings
Drone uses environment variables for runtime settings and configuration, such as GitHub, GitLab, plugins and more. These settings are loaded from `/etc/drone/dronerc`.
## Starting, Stopping, Logs
Commands to start, stop and restart Drone:
```
sudo start drone
sudo stop drone
sudo restart drone
```
And to view the Drone logs:
```
sudo cat /var/log/upstart/drone.log
```

30
docs/setup/upgrade.md
View file

@ -1,30 +0,0 @@
# Upgrading
> Warning. There is no automated migration from 0.3 to 0.4 due to substantial changes in database structure.
Drone is built continuously, with updates available daily. In order to upgrade Drone you must first stop and remove your running Drone instance:
```
sudo docker stop drone
sudo docker rm drone
```
Pull the latest Drone image:
```
sudo docker pull drone/drone:0.4
```
Re-run the container using the latest Drone image:
```
sudo docker run \
--volume /var/lib/drone:/var/lib/drone \
--volume /var/run/docker.sock:/var/run/docker.sock \
--env-file /etc/drone/dronerc \
--restart=always \
--publish=80:8000 \
--detach=true \
--name=drone \
drone/drone:0.4
```

5
static/static.go
View file

@ -7,11 +7,6 @@ import (
)
//go:generate go run ../contrib/generate-js.go -dir scripts/ -o scripts_gen/drone.min.js
//go:generate go run ../contrib/generate-api-docs.go -input ../docs/swagger.yml -template ../template/amber/swagger.amber -output docs_gen/api/index.html
//go:generate go run ../contrib/generate-docs.go -input ../docs/build/README.md -name Builds -template ../template/amber/docs.amber -output docs_gen/build/
//go:generate go run ../contrib/generate-docs.go -input ../docs/plugin/README.md -name Plugins -template ../template/amber/docs.amber -output docs_gen/plugin/
//go:generate go run ../contrib/generate-docs.go -input ../docs/setup/README.md -name Install -template ../template/amber/docs.amber -output docs_gen/setup/
//go:generate go run ../contrib/generate-docs.go -input ../docs/cli/README.md -name CLI -template ../template/amber/docs.amber -output docs_gen/cli/
//go:generate sassc --style compact styles/style.sass styles_gen/style.css
//go:generate go-bindata-assetfs -ignore "\\.go" -pkg static -o static_gen.go ./...