mirror of
https://github.com/woodpecker-ci/woodpecker.git
synced 2024-12-31 12:48:42 +00:00
removing deprecated files
This commit is contained in:
Brad Rydzewski
parent
f9bba48e19
commit
e64ec7cf88
45 changed files with 0 additions and 2081 deletions
18
Makefile
18
Makefile
|
|
@ -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/
|
||||
|
|
|
|||
|
|
@ -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 }
|
||||
|
|
@ -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
11
docs/build/README.md
vendored
|
|
@ -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
0
docs/build/badges.md
vendored
52
docs/build/build.md
vendored
52
docs/build/build.md
vendored
|
|
@ -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
30
docs/build/cache.md
vendored
|
|
@ -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
36
docs/build/clone.md
vendored
|
|
@ -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
47
docs/build/deploy.md
vendored
|
|
@ -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
61
docs/build/env.md
vendored
|
|
@ -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
41
docs/build/index.md
vendored
|
|
@ -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
83
docs/build/matrix.md
vendored
|
|
@ -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
34
docs/build/notify.md
vendored
|
|
@ -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
39
docs/build/publish.md
vendored
|
|
@ -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
79
docs/build/secrets.md
vendored
|
|
@ -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
0
docs/build/selenium.md
vendored
42
docs/build/services.md
vendored
42
docs/build/services.md
vendored
|
|
@ -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.
|
||||
|
|
@ -1,4 +0,0 @@
|
|||
* [Install](index.md)
|
||||
* [Local Builds](builds.md)
|
||||
* [Encrypt Secrets](secrets.md)
|
||||
* [Add Machines](machines.md)
|
||||
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
|
@ -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
|
||||
```
|
||||
|
|
@ -1,3 +0,0 @@
|
|||
# Overview
|
||||
|
||||
> Coming Soon
|
||||
|
|
@ -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
|
||||
```
|
||||
|
|
@ -1,3 +0,0 @@
|
|||
* [Overview](index.md)
|
||||
* [Example](example.md)
|
||||
* [Publish](publish.md)
|
||||
|
|
@ -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"]
|
||||
```
|
||||
|
|
@ -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
|
||||
|
|
@ -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).
|
||||
|
|
@ -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)
|
||||
|
|
@ -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
|
||||
|
|
@ -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
|
||||
```
|
||||
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
|
@ -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
|
||||
```
|
||||
|
|
@ -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;'
|
||||
```
|
||||
|
|
@ -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`.
|
||||
|
|
@ -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
|
||||
```
|
||||
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
|
@ -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 \
|
||||
```
|
||||
|
|
@ -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.
|
||||
|
|
@ -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
|
||||
```
|
||||
|
|
@ -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
|
||||
```
|
||||
|
|
@ -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 ./...
|
||||
|
|
|
|||
Loading…
Reference in a new issue