flux: github.com/weaveworks/flux/pkg/job Index | Files

package job

import "github.com/weaveworks/flux/pkg/job"

Index

Package Files

job.go status_cache.go

type ID Uses

type ID string

type Job Uses

type Job struct {
    ID  ID
    Do  JobFunc
}

type JobFunc Uses

type JobFunc func(log.Logger) error

type Queue Uses

type Queue struct {
    // contains filtered or unexported fields
}

Queue is an unbounded queue of jobs; enqueuing a job will always proceed, while dequeuing is done by receiving from a channel. It is also possible to iterate over the current list of jobs.

func NewQueue Uses

func NewQueue(stop <-chan struct{}, wg *sync.WaitGroup) *Queue

func (*Queue) Enqueue Uses

func (q *Queue) Enqueue(j *Job)

Enqueue puts a job onto the queue. It will block until the queue's loop can accept the job; but this does _not_ depend on a job being dequeued and will always proceed eventually.

func (*Queue) ForEach Uses

func (q *Queue) ForEach(fn func(int, *Job) bool)

func (*Queue) Len Uses

func (q *Queue) Len() int

This is not guaranteed to be up-to-date; i.e., it is possible to receive from `q.Ready()` or enqueue an item, then see the same length as before, temporarily.

func (*Queue) Ready Uses

func (q *Queue) Ready() <-chan *Job

Ready returns a channel that can be used to dequeue items. Note that dequeuing is not atomic: you may still see the dequeued item with ForEach, for a time.

func (*Queue) Sync Uses

func (q *Queue) Sync()

Block until any previous operations have completed. Note that this is only meaningful if you are using the queue from a single other goroutine; i.e., it makes sense to do, say,

q.Enqueue(j)
q.Sync()
fmt.Printf("Queue length is %d\n", q.Len())

but only because those statements are sequential in a single thread. So this is really only useful for testing.

type Result Uses

type Result struct {
    Revision string        `json:"revision,omitempty"`
    Spec     *update.Spec  `json:"spec,omitempty"`
    Result   update.Result `json:"result,omitempty"`
}

Result looks like CommitEventMetadata, because that's what we used to send. But in the interest of breaking cycles before they happen, it's (almost) duplicated here.

type Status Uses

type Status struct {
    Result       Result
    Err          string
    StatusString StatusString
}

Status holds the possible states of a job; either,

1. queued or otherwise pending
2. succeeded with a job-specific result
3. failed, resulting in an error and possibly a job-specific result

func (Status) Error Uses

func (s Status) Error() string

type StatusCache Uses

type StatusCache struct {
    // Size is the number of statuses to store. When full, jobs are evicted in FIFO ordering.
    // oldest ones will be evicted to make room.
    Size int

    sync.RWMutex
    // contains filtered or unexported fields
}

func (*StatusCache) SetStatus Uses

func (c *StatusCache) SetStatus(id ID, status Status)

func (*StatusCache) Status Uses

func (c *StatusCache) Status(id ID) (Status, bool)

type StatusString Uses

type StatusString string
const (
    StatusQueued    StatusString = "queued"
    StatusRunning   StatusString = "running"
    StatusFailed    StatusString = "failed"
    StatusSucceeded StatusString = "succeeded"
)

Package job imports 3 packages (graph). Updated 2019-09-29. Refresh now. Tools for package owners.