README
¶
Travis Worker
Installing Travis Worker
Configuring Travis Worker
Travis Worker is configured with environment variables or command line flags via the codegangsta/cli library. A list of the non-dynamic flags and environment variables may be found by invoking the built-in help system:
travis-worker --help
Configuring the requested provider
Each provider requires its own configuration, which must be provided via
environment variables namespaced by TRAVIS_WORKER_{PROVIDER}_, e.g. for the
docker provider:
export TRAVIS_WORKER_DOCKER_ENDPOINT="tcp://localhost:4243"
export TRAVIS_WORKER_DOCKER_PRIVILEGED="false"
export TRAVIS_WORKER_DOCKER_CERT_PATH="/etc/secret-docker-cert-stuff"
Verifying and exporting configuration
To inspect the parsed configuration in a format that can be used as a base
environment variable configuration, use the --echo-config flag, which will
exit immediately after writing to stdout:
travis-worker --echo-config
Running Travis Worker
deppy restoremake${GOPATH%%:*}/bin/travis-worker
C-c will stop the worker. Note that any VMs for builds that were still running will have to be cleaned up manually.
Stopping Travis Worker
Travis Worker has two shutdown modes: Graceful and immediate. The graceful shutdown will tell the worker to not start any additional jobs, but finish the jobs it is currently running before it shuts down. The immediate shutdown will make the worker stop the jobs it's working on and requeue them, and clean up any open resources (shut down VMs, cleanly close connections, etc.)
To start a graceful shutdown, send an INT signal to the worker (for example
using kill -INT). To start an immediate shutdown, send a TERM signal to the
worker (for example using kill -TERM).
License and Copyright Information
See LICENSE file.
Copyright © 2014 Travis CI GmbH
Documentation
¶
Index ¶
Constants ¶
This section is empty.
Variables ¶
var ( LogWriterTick = 500 * time.Millisecond // This is a bit of a magic number, calculated like this: The maximum // Pusher payload is 10 kB (or 10 KiB, who knows, but let's go with 10 // kB since that is smaller). Looking at the travis-logs source, the // current message overhead (i.e. the part of the payload that isn't // the content of the log part) is 42 bytes + the length of the JSON- // encoded ID and the length of the JSON-encoded sequence number. A 64- // bit number is up to 20 digits long, so that means (assuming we don't // go over 64-bit numbers) the overhead is up to 82 bytes. That means // we can send up to 9918 bytes of content. However, the JSON-encoded // version of a string can be significantly longer than the raw bytes. // Worst case that I could find is "<", which with the Go JSON encoder // becomes "\u003c" (i.e. six bytes long). So, given a string of just // left angle brackets, the string would become six times as long, // meaning that the longest string we can take is 1653. We could still // get errors if we go over 64-bit numbers, but I find the likeliness // of that happening to both the sequence number, the ID, and us maxing // out the worst-case logs to be quite unlikely, so I'm willing to live // with that. --Henrik LogChunkSize = 1653 )
var ( // VersionString is the git describe version set at build time VersionString = "?" // RevisionString is the git revision set at build time RevisionString = "?" // GeneratedString is the build date set at build time GeneratedString = "?" )
Functions ¶
This section is empty.
Types ¶
type BuildPayload ¶
type BuildScriptGenerator ¶
A BuildScriptGenerator generates a build script for a given job payload.
func NewBuildScriptGenerator ¶
func NewBuildScriptGenerator(cfg *config.Config) BuildScriptGenerator
NewBuildScriptGenerator creates a generator backed by an HTTP API.
type BuildScriptGeneratorError ¶
type BuildScriptGeneratorError struct {
// true when this error can be recovered by retrying later
Recover bool
// contains filtered or unexported fields
}
A BuildScriptGeneratorError is sometimes used by the Generate method on a BuildScriptGenerator to return more metadata about an error.
type CommandDispatcher ¶
type CommandDispatcher struct {
// contains filtered or unexported fields
}
func NewCommandDispatcher ¶
func NewCommandDispatcher(ctx gocontext.Context, conn *amqp.Connection) *CommandDispatcher
func (*CommandDispatcher) Run ¶
func (d *CommandDispatcher) Run()
func (*CommandDispatcher) Subscribe ¶
func (d *CommandDispatcher) Subscribe(id uint64, ch chan<- struct{}) error
func (*CommandDispatcher) Unsubscribe ¶
func (d *CommandDispatcher) Unsubscribe(id uint64)
type FinishState ¶
type FinishState string
FinishState is the state that a job finished with (such as pass/fail/etc.). You should not provide a string directly, but use one of the FinishStateX constants defined in this package.
const ( FinishStatePassed FinishState = "passed" FinishStateFailed FinishState = "failed" FinishStateErrored FinishState = "errored" FinishStateCancelled FinishState = "cancelled" )
Valid finish states for the FinishState type
type Job ¶
type Job interface {
Payload() *JobPayload
RawPayload() *simplejson.Json
StartAttributes() *backend.StartAttributes
Received() error
Started() error
Error(context.Context, string) error
Requeue() error
Finish(FinishState) error
LogWriter(context.Context) (LogWriter, error)
}
A Job ties togeher all the elements required for a build job
type JobJobPayload ¶
type JobPayload ¶
type JobPayload struct {
Type string `json:"type"`
Job JobJobPayload `json:"job"`
Build BuildPayload `json:"source"`
Repository RepositoryPayload `json:"repository"`
UUID string `json:"uuid"`
Config map[string]interface{} `json:"config"`
}
JobPayload is the payload we receive over RabbitMQ.
type JobQueue ¶
type JobQueue struct {
// contains filtered or unexported fields
}
A JobQueue allows getting Jobs out of an AMQP queue.
func NewJobQueue ¶
func NewJobQueue(conn *amqp.Connection, queue string) (*JobQueue, error)
NewJobQueue creates a JobQueue backed by the given AMQP connections and connects to the AMQP queue with the given name. The queue will be declared in AMQP when this function is called, so an error could be raised if the queue already exists, but with different attributes than we expect.
type LogWriter ¶
type LogWriter interface {
io.WriteCloser
WriteAndClose([]byte) (int, error)
SetTimeout(time.Duration)
Timeout() <-chan time.Time
SetMaxLogLength(int)
}
func NewLogWriter ¶
type Processor ¶
type Processor struct {
SkipShutdownOnLogTimeout bool
// contains filtered or unexported fields
}
A Processor will process build jobs on a channel, one by one, until it is told to shut down or the channel of build jobs closes.
func NewProcessor ¶
func NewProcessor(ctx gocontext.Context, hostname string, buildJobsQueue *JobQueue, provider backend.Provider, generator BuildScriptGenerator, canceller Canceller, hardTimeout time.Duration) (*Processor, error)
NewProcessor creates a new processor that will run the build jobs on the given channel using the given provider and getting build scripts from the generator.
func (*Processor) GracefulShutdown ¶
func (p *Processor) GracefulShutdown()
GracefulShutdown tells the processor to finish the job it is currently processing, but not pick up any new jobs. This method will return immediately, the processor is done when Run() returns.
type ProcessorPool ¶
type ProcessorPool struct {
Context gocontext.Context
Conn *amqp.Connection
Provider backend.Provider
Generator BuildScriptGenerator
Canceller Canceller
Hostname string
HardTimeout time.Duration
SkipShutdownOnLogTimeout bool
// contains filtered or unexported fields
}
A ProcessorPool spins up multiple Processors handling build jobs from the same queue.
func NewProcessorPool ¶
func NewProcessorPool(hostname string, ctx gocontext.Context, hardTimeout time.Duration, amqpConn *amqp.Connection, provider backend.Provider, generator BuildScriptGenerator, canceller Canceller) *ProcessorPool
func (*ProcessorPool) GracefulShutdown ¶
func (p *ProcessorPool) GracefulShutdown()
GracefulShutdown causes each processor in the pool to start its graceful shutdown.
Source Files
Directories