tcqueueevents

package
v44.22.1 Latest Latest
Warning

This package is not in the latest version of its module.

 Go to latest Published: Oct 18, 2022 License: MPL-2.0 Imports: 3 Imported by: 0

Documentation

Overview

This package was generated from the schema defined at /references/queue/v1/exchanges.json The queue service is responsible for accepting tasks and track their state as they are executed by workers. In order ensure they are eventually resolved.

This document describes AMQP exchanges offered by the queue, which allows third-party listeners to monitor tasks as they progress to resolution. These exchanges targets the following audience:

  • Schedulers, who takes action after tasks are completed,
  • Workers, who wants to listen for new or canceled tasks (optional),
  • Tools, that wants to update their view as task progress.

You'll notice that all the exchanges in the document shares the same routing key pattern. This makes it very easy to bind to all messages about a certain kind tasks.

**Task specific routes**, a task can define a task specific route using the `task.routes` property. See task creation documentation for details on permissions required to provide task specific routes. If a task has the entry `'notify.by-email'` in as task specific route defined in `task.routes` all messages about this task will be CC'ed with the routing-key `'route.notify.by-email'`.

These routes will always be prefixed `route.`, so that cannot interfere with the _primary_ routing key as documented here. Notice that the _primary_ routing key is always prefixed `primary.`. This is ensured in the routing key reference, so API clients will do this automatically.

Please, note that the way RabbitMQ works, the message will only arrive in your queue once, even though you may have bound to the exchange with multiple routing key patterns that matches more of the CC'ed routing routing keys.

**Delivery guarantees**, most operations on the queue are idempotent, which means that if repeated with the same arguments then the requests will ensure completion of the operation and return the same response. This is useful if the server crashes or the TCP connection breaks, but when re-executing an idempotent operation, the queue will also resend any related AMQP messages. Hence, messages may be repeated.

This shouldn't be much of a problem, as the best you can achieve using confirm messages with AMQP is at-least-once delivery semantics. Hence, this only prevents you from obtaining at-most-once delivery semantics.

**Remark**, some message generated by timeouts maybe dropped if the server crashes at wrong time. Ideally, we'll address this in the future. For now we suggest you ignore this corner case, and notify us if this corner case is of concern to you.

See:

How to use this package

This package is designed to sit on top of https://pkg.go.dev/github.com/taskcluster/pulse-go/pulse. Please read the pulse package overview to get an understanding of how the pulse client is implemented in go.

This package provides two things in addition to the basic pulse package: structured types for unmarshaling pulse message bodies into, and custom Binding interfaces, for defining the fixed strings for task cluster exchange names, and routing keys as structured types.

For example, when specifying a binding, rather than using: 

pulse.Bind(
	"*.*.*.*.*.*.gaia.#",
	"exchange/taskcluster-queue/v1/task-defined",
)

You can rather use: 

queueevents.TaskDefined{WorkerType: "gaia"}

In addition, this means that you will also get objects in your callback method like *queueevents.TaskDefinedMessage rather than just interface{}.

Example (TaskclusterSniffer) 
package main

import (
	"fmt"

	"github.com/streadway/amqp"
	"github.com/taskcluster/pulse-go/pulse"
	"github.com/taskcluster/taskcluster/v44/clients/client-go/tcqueueevents"
)

func main() {
	// Passing all empty strings:
	// empty user => use PULSE_USERNAME env var
	// empty password => use PULSE_PASSWORD env var
	// empty url => connect to production
	conn := pulse.NewConnection("", "", "")
	_, _ = conn.Consume(
		"taskprocessing", // queue name
		func(message interface{}, delivery amqp.Delivery) { // callback function to pass messages to
			switch t := message.(type) {
			case *tcqueueevents.TaskDefinedMessage:
				fmt.Println("Task " + t.Status.TaskID + " defined")
				fmt.Println(string(delivery.Body))
			case *tcqueueevents.TaskRunningMessage:
				fmt.Println("Task " + t.Status.TaskID + " running, (taken until " + t.TakenUntil.String() + " by worker " + t.WorkerID + ")")
			default:
				panic(fmt.Errorf("Unrecognised message type %T!", t))
			}
			fmt.Println("===========")
			_ = delivery.Ack(false) // acknowledge message *after* processing
		},
		1,     // prefetch 1 message at a time
		false, // don't auto-acknowledge messages
		tcqueueevents.TaskDefined{WorkerType: "gaia", ProvisionerID: "aws-provisioner"},
		tcqueueevents.TaskRunning{WorkerType: "gaia", ProvisionerID: "aws-provisioner"})
	_, _ = conn.Consume( // a second workflow to manage concurrently
		"", // empty name implies anonymous queue
		func(message interface{}, delivery amqp.Delivery) { // simpler callback than before
			fmt.Println("A buildbot message was received")
			fmt.Println("===========")
		},
		1,    // prefetch
		true, // auto acknowledge, so no need to call delivery.Ack
		pulse.Bind( // routing key and exchange to get messages from
			"#", // get *all* normalized buildbot messages
			"exchange/build/normalized"))
	// wait forever
	forever := make(chan bool)
	<-forever
}

Output:

Index

Examples

Constants

This section is empty.

Variables

This section is empty.

Functions

This section is empty.

Types

type Artifact 

type Artifact struct {

	// Expected content-type of the artifact.  This is informational only:
	// it is suitable for use to choose an icon for the artifact, for example.
	// The accurate content-type of the artifact can only be determined by
	// downloading it.
	//
	// Max length: 255
	ContentType string `json:"contentType"`

	// Date and time after which the artifact created will be automatically
	// deleted by the queue.
	Expires tcclient.Time `json:"expires"`

	// Name of the artifact that was created, this is useful if you want to
	// attempt to fetch the artifact. But keep in mind that just because an
	// artifact is created doesn't mean that it's immediately available.
	//
	// Max length: 1024
	Name string `json:"name"`

	// This is the `storageType` for the request that was used to create the
	// artifact.  Note that artifacts with the `s3` storage type do not produce
	// this message.
	//
	// Possible values:
	//   * "reference"
	//   * "link"
	//   * "error"
	//   * "object"
	StorageType string `json:"storageType"`
}

Information about the artifact that was created

type ArtifactCreated 

type ArtifactCreated struct {
	RoutingKeyKind string `mwords:"*"`
	TaskID         string `mwords:"*"`
	RunID          string `mwords:"*"`
	WorkerGroup    string `mwords:"*"`
	WorkerID       string `mwords:"*"`
	ProvisionerID  string `mwords:"*"`
	WorkerType     string `mwords:"*"`
	SchedulerID    string `mwords:"*"`
	TaskGroupID    string `mwords:"*"`
	Reserved       string `mwords:"#"`
}

Whenever the `createArtifact` end-point is called, the queue will create a record of the artifact and post a message on this exchange. All of this happens before the queue returns a signed URL for the caller to upload the actual artifact with (pending on `storageType`).

This means that the actual artifact is rarely available when this message is posted. But it is not unreasonable to assume that the artifact will will become available at some point later. Most signatures will expire in 30 minutes or so, forcing the uploader to call `createArtifact` with the same payload again in-order to continue uploading the artifact.

However, in most cases (especially for small artifacts) it's very reasonable assume the artifact will be available within a few minutes. This property means that this exchange is mostly useful for tools monitoring task evaluation. One could also use it count number of artifacts per task, or _index_ artifacts though in most cases it'll be smarter to index artifacts after the task in question have completed successfully.

*NOTE*: this message is currently only sent for reference and error artifacts. This will be remedied in a future version of Taskcluster.

See #artifactCreated

func (ArtifactCreated) ExchangeName 

func (binding ArtifactCreated) ExchangeName() string

func (ArtifactCreated) NewPayloadObject 

func (binding ArtifactCreated) NewPayloadObject() interface{}

func (ArtifactCreated) RoutingKey 

func (binding ArtifactCreated) RoutingKey() string

type ArtifactCreatedMessage 

type ArtifactCreatedMessage struct {

	// Information about the artifact that was created
	Artifact Artifact `json:"artifact"`

	// Id of the run on which artifact was created.
	//
	// Mininum:    0
	// Maximum:    1000
	RunID int64 `json:"runId"`

	// A representation of **task status** as known by the queue
	Status TaskStatusStructure `json:"status"`

	// Message version
	//
	// Possible values:
	//   * 1
	Version int64 `json:"version"`

	// Identifier for the worker-group within which the run with the created
	// artifacted is running.
	//
	// Syntax:     ^([a-zA-Z0-9-_]*)$
	// Min length: 1
	// Max length: 38
	WorkerGroup string `json:"workerGroup"`

	// Identifier for the worker within which the run with the created artifact
	// is running.
	//
	// Syntax:     ^([a-zA-Z0-9-_]*)$
	// Min length: 1
	// Max length: 38
	WorkerID string `json:"workerId"`
}

Message reporting a new artifact has been created for a given task.

type RunInformation 

type RunInformation struct {

	// Reason for the creation of this run,
	// **more reasons may be added in the future**.
	//
	// Possible values:
	//   * "scheduled"
	//   * "retry"
	//   * "task-retry"
	//   * "rerun"
	//   * "exception"
	ReasonCreated string `json:"reasonCreated"`

	// Reason that run was resolved, this is mainly
	// useful for runs resolved as `exception`.
	// Note, **more reasons may be added in the future**, also this
	// property is only available after the run is resolved. Some of these
	// reasons, notably `intermittent-task`, `worker-shutdown`, and
	// `claim-expired`, will trigger an automatic retry of the task.
	// Note that 'superseded' is here only for compatibility, as that
	// functionality has been removed.
	//
	// Possible values:
	//   * "completed"
	//   * "failed"
	//   * "deadline-exceeded"
	//   * "canceled"
	//   * "claim-expired"
	//   * "worker-shutdown"
	//   * "malformed-payload"
	//   * "resource-unavailable"
	//   * "internal-error"
	//   * "intermittent-task"
	//   * "superseded"
	ReasonResolved string `json:"reasonResolved,omitempty"`

	// Date-time at which this run was resolved, ie. when the run changed
	// state from `running` to either `completed`, `failed` or `exception`.
	// This property is only present after the run as been resolved.
	Resolved tcclient.Time `json:"resolved,omitempty"`

	// Id of this task run, `run-id`s always starts from `0`
	//
	// Mininum:    0
	// Maximum:    1000
	RunID int64 `json:"runId"`

	// Date-time at which this run was scheduled, ie. when the run was
	// created in state `pending`.
	Scheduled tcclient.Time `json:"scheduled"`

	// Date-time at which this run was claimed, ie. when the run changed
	// state from `pending` to `running`. This property is only present
	// after the run has been claimed.
	Started tcclient.Time `json:"started,omitempty"`

	// State of this run
	//
	// Possible values:
	//   * "pending"
	//   * "running"
	//   * "completed"
	//   * "failed"
	//   * "exception"
	State string `json:"state"`

	// Time at which the run expires and is resolved as `failed`, if the
	// run isn't reclaimed. Note, only present after the run has been
	// claimed.
	TakenUntil tcclient.Time `json:"takenUntil,omitempty"`

	// Identifier for group that worker who executes this run is a part of,
	// this identifier is mainly used for efficient routing.
	// Note, this property is only present after the run is claimed.
	//
	// Syntax:     ^([a-zA-Z0-9-_]*)$
	// Min length: 1
	// Max length: 38
	WorkerGroup string `json:"workerGroup,omitempty"`

	// Identifier for worker evaluating this run within given
	// `workerGroup`. Note, this property is only available after the run
	// has been claimed.
	//
	// Syntax:     ^([a-zA-Z0-9-_]*)$
	// Min length: 1
	// Max length: 38
	WorkerID string `json:"workerId,omitempty"`
}

JSON object with information about a run

type Task 

type Task struct {

	// Arbitrary key-value tags (only strings limited to 4k). These can be used
	// to attach informal metadata to a task. Use this for informal tags that
	// tasks can be classified by. You can also think of strings here as
	// candidates for formal metadata. Something like
	// `purpose: 'build' || 'test'` is a good example.
	//
	// Default:    {}
	//
	// Map entries:
	// Max length: 4096
	Tags map[string]string `json:"tags"`
}

Subset of a task definition

type TaskCompleted 

type TaskCompleted struct {
	RoutingKeyKind string `mwords:"*"`
	TaskID         string `mwords:"*"`
	RunID          string `mwords:"*"`
	WorkerGroup    string `mwords:"*"`
	WorkerID       string `mwords:"*"`
	ProvisionerID  string `mwords:"*"`
	WorkerType     string `mwords:"*"`
	SchedulerID    string `mwords:"*"`
	TaskGroupID    string `mwords:"*"`
	Reserved       string `mwords:"#"`
}

When a task is successfully completed by a worker a message is posted this exchange. This message is routed using the `runId`, `workerGroup` and `workerId` that completed the task. But information about additional runs is also available from the task status structure.

See #taskCompleted

func (TaskCompleted) ExchangeName 

func (binding TaskCompleted) ExchangeName() string

func (TaskCompleted) NewPayloadObject 

func (binding TaskCompleted) NewPayloadObject() interface{}

func (TaskCompleted) RoutingKey 

func (binding TaskCompleted) RoutingKey() string

type TaskCompletedMessage 

type TaskCompletedMessage struct {

	// Id of the run that completed the task
	//
	// Mininum:    0
	// Maximum:    1000
	RunID int64 `json:"runId"`

	// A representation of **task status** as known by the queue
	Status TaskStatusStructure `json:"status"`

	// Subset of a task definition containing values that are useful for determining
	// whether a message is interesting to the receiver. Where the full task
	// definition is required, the receiver should call queue.task to download that
	// definition.
	Task Var `json:"task,omitempty"`

	// Message version
	//
	// Possible values:
	//   * 1
	Version int64 `json:"version"`

	// Identifier for the worker-group within which this run ran.
	//
	// Syntax:     ^([a-zA-Z0-9-_]*)$
	// Min length: 1
	// Max length: 38
	WorkerGroup string `json:"workerGroup"`

	// Identifier for the worker that executed this run.
	//
	// Syntax:     ^([a-zA-Z0-9-_]*)$
	// Min length: 1
	// Max length: 38
	WorkerID string `json:"workerId"`
}

Message reporting that a task has complete successfully.

type TaskDefined 

type TaskDefined struct {
	RoutingKeyKind string `mwords:"*"`
	TaskID         string `mwords:"*"`
	RunID          string `mwords:"*"`
	WorkerGroup    string `mwords:"*"`
	WorkerID       string `mwords:"*"`
	ProvisionerID  string `mwords:"*"`
	WorkerType     string `mwords:"*"`
	SchedulerID    string `mwords:"*"`
	TaskGroupID    string `mwords:"*"`
	Reserved       string `mwords:"#"`
}

When a task is created or just defined a message is posted to this exchange.

This message exchange is mainly useful when tasks are created with dependencies on incomplete tasks, as this does not make the task `pending`. Thus, no `taskPending` message is published.

See #taskDefined

func (TaskDefined) ExchangeName 

func (binding TaskDefined) ExchangeName() string

func (TaskDefined) NewPayloadObject 

func (binding TaskDefined) NewPayloadObject() interface{}

func (TaskDefined) RoutingKey 

func (binding TaskDefined) RoutingKey() string

type TaskDefinedMessage 

type TaskDefinedMessage struct {

	// A representation of **task status** as known by the queue
	Status TaskStatusStructure `json:"status"`

	// Subset of a task definition containing values that are useful for determining
	// whether a message is interesting to the receiver. Where the full task
	// definition is required, the receiver should call queue.task to download that
	// definition.
	Task Var `json:"task,omitempty"`

	// Message version
	//
	// Possible values:
	//   * 1
	Version int64 `json:"version"`
}

Message reporting that a task has been defined. The task may or may not be _scheduled_ too.

type TaskException 

type TaskException struct {
	RoutingKeyKind string `mwords:"*"`
	TaskID         string `mwords:"*"`
	RunID          string `mwords:"*"`
	WorkerGroup    string `mwords:"*"`
	WorkerID       string `mwords:"*"`
	ProvisionerID  string `mwords:"*"`
	WorkerType     string `mwords:"*"`
	SchedulerID    string `mwords:"*"`
	TaskGroupID    string `mwords:"*"`
	Reserved       string `mwords:"#"`
}

Whenever Taskcluster fails to run a message is posted to this exchange. This happens if the task isn't completed before its `deadlìne`, all retries failed (i.e. workers stopped responding), the task was canceled by another entity, or the task carried a malformed payload.

The specific _reason_ is evident from that task status structure, refer to the `reasonResolved` property for the last run.

See #taskException

func (TaskException) ExchangeName 

func (binding TaskException) ExchangeName() string

func (TaskException) NewPayloadObject 

func (binding TaskException) NewPayloadObject() interface{}

func (TaskException) RoutingKey 

func (binding TaskException) RoutingKey() string

type TaskExceptionMessage 

type TaskExceptionMessage struct {

	// Id of the last run for the task, not provided if `deadline`
	// was exceeded before a run was started.
	//
	// Mininum:    0
	// Maximum:    1000
	RunID int64 `json:"runId,omitempty"`

	// A representation of **task status** as known by the queue
	Status TaskStatusStructure `json:"status"`

	// Subset of a task definition containing values that are useful for determining
	// whether a message is interesting to the receiver. Where the full task
	// definition is required, the receiver should call queue.task to download that
	// definition.
	Task Var `json:"task,omitempty"`

	// Message version
	//
	// Possible values:
	//   * 1
	Version int64 `json:"version"`

	// Identifier for the worker-group within which the last attempt of the task
	// ran. Not provided, if `deadline` was exceeded before a run was started.
	//
	// Syntax:     ^([a-zA-Z0-9-_]*)$
	// Min length: 1
	// Max length: 38
	WorkerGroup string `json:"workerGroup,omitempty"`

	// Identifier for the last worker that failed to report, causing the task
	// to fail. Not provided, if `deadline` was exceeded before a run
	// was started.
	//
	// Syntax:     ^([a-zA-Z0-9-_]*)$
	// Min length: 1
	// Max length: 38
	WorkerID string `json:"workerId,omitempty"`
}

Message reporting that Taskcluster have failed to run a task.

type TaskFailed 

type TaskFailed struct {
	RoutingKeyKind string `mwords:"*"`
	TaskID         string `mwords:"*"`
	RunID          string `mwords:"*"`
	WorkerGroup    string `mwords:"*"`
	WorkerID       string `mwords:"*"`
	ProvisionerID  string `mwords:"*"`
	WorkerType     string `mwords:"*"`
	SchedulerID    string `mwords:"*"`
	TaskGroupID    string `mwords:"*"`
	Reserved       string `mwords:"#"`
}

When a task ran, but failed to complete successfully a message is posted to this exchange. This is same as worker ran task-specific code, but the task specific code exited non-zero.

See #taskFailed

func (TaskFailed) ExchangeName 

func (binding TaskFailed) ExchangeName() string

func (TaskFailed) NewPayloadObject 

func (binding TaskFailed) NewPayloadObject() interface{}

func (TaskFailed) RoutingKey 

func (binding TaskFailed) RoutingKey() string

type TaskFailedMessage 

type TaskFailedMessage struct {

	// Id of the run that failed.
	//
	// Mininum:    0
	// Maximum:    1000
	RunID int64 `json:"runId"`

	// A representation of **task status** as known by the queue
	Status TaskStatusStructure `json:"status"`

	// Subset of a task definition containing values that are useful for determining
	// whether a message is interesting to the receiver. Where the full task
	// definition is required, the receiver should call queue.task to download that
	// definition.
	Task Var `json:"task,omitempty"`

	// Message version
	//
	// Possible values:
	//   * 1
	Version int64 `json:"version"`

	// Identifier for the worker-group within which this run ran.
	//
	// Syntax:     ^([a-zA-Z0-9-_]*)$
	// Min length: 1
	// Max length: 38
	WorkerGroup string `json:"workerGroup"`

	// Identifier for the worker that executed this run.
	//
	// Syntax:     ^([a-zA-Z0-9-_]*)$
	// Min length: 1
	// Max length: 38
	WorkerID string `json:"workerId"`
}

Message reporting that a task failed to complete successfully.

type TaskGroupResolved 

type TaskGroupResolved struct {
	RoutingKeyKind string `mwords:"*"`
	TaskGroupID    string `mwords:"*"`
	SchedulerID    string `mwords:"*"`
	Reserved       string `mwords:"#"`
}

A message is published on task-group-resolved whenever all submitted tasks (whether scheduled or unscheduled) for a given task group have been resolved, regardless of whether they resolved as successful or not. A task group may be resolved multiple times, since new tasks may be submitted against an already resolved task group.

See #taskGroupResolved

func (TaskGroupResolved) ExchangeName 

func (binding TaskGroupResolved) ExchangeName() string

func (TaskGroupResolved) NewPayloadObject 

func (binding TaskGroupResolved) NewPayloadObject() interface{}

func (TaskGroupResolved) RoutingKey 

func (binding TaskGroupResolved) RoutingKey() string

type TaskGroupResolvedMessage 

type TaskGroupResolvedMessage struct {

	// Identifier for the scheduler that created this task-group.
	//
	// Syntax:     ^([a-zA-Z0-9-_]*)$
	// Min length: 1
	// Max length: 38
	SchedulerID string `json:"schedulerId"`

	// Identifier for the task-group being listed.
	//
	// Syntax:     ^[A-Za-z0-9_-]{8}[Q-T][A-Za-z0-9_-][CGKOSWaeimquy26-][A-Za-z0-9_-]{10}[AQgw]$
	TaskGroupID string `json:"taskGroupId"`

	// Message version
	//
	// Possible values:
	//   * 1
	Version int64 `json:"version,omitempty"`
}

Message written once a task group has no tasks to be run. It is possible for a task group to later have another task added, in which case this message will be sent again once it finishes.

type TaskMetadata 

type TaskMetadata struct {

	// Human readable description of the task, please **explain** what the
	// task does. A few lines of documentation is not going to hurt you.
	//
	// Max length: 32768
	Description string `json:"description"`

	// Human readable name of task, used to very briefly given an idea about
	// what the task does.
	//
	// Max length: 255
	Name string `json:"name"`

	// Entity who caused this task, not necessarily a person with email who did
	// `hg push` as it could be automation bots as well. The entity we should
	// contact to ask why this task is here.
	//
	// Max length: 255
	Owner string `json:"owner"`

	// Link to source of this task, should specify a file, revision and
	// repository. This should be place someone can go an do a git/hg blame
	// to who came up with recipe for this task.
	//
	// Syntax:     ^(https?|ssh)://
	// Max length: 4096
	Source string `json:"source"`
}

Required task metadata

type TaskPending 

type TaskPending struct {
	RoutingKeyKind string `mwords:"*"`
	TaskID         string `mwords:"*"`
	RunID          string `mwords:"*"`
	WorkerGroup    string `mwords:"*"`
	WorkerID       string `mwords:"*"`
	ProvisionerID  string `mwords:"*"`
	WorkerType     string `mwords:"*"`
	SchedulerID    string `mwords:"*"`
	TaskGroupID    string `mwords:"*"`
	Reserved       string `mwords:"#"`
}

When a task becomes `pending` a message is posted to this exchange.

This is useful for workers who doesn't want to constantly poll the queue for new tasks. The queue will also be authority for task states and claims. But using this exchange workers should be able to distribute work efficiently and they would be able to reduce their polling interval significantly without affecting general responsiveness.

See #taskPending

func (TaskPending) ExchangeName 

func (binding TaskPending) ExchangeName() string

func (TaskPending) NewPayloadObject 

func (binding TaskPending) NewPayloadObject() interface{}

func (TaskPending) RoutingKey 

func (binding TaskPending) RoutingKey() string

type TaskPendingMessage 

type TaskPendingMessage struct {

	// Id of run that became pending, `run-id`s always starts from 0
	//
	// Mininum:    0
	// Maximum:    1000
	RunID int64 `json:"runId"`

	// A representation of **task status** as known by the queue
	Status TaskStatusStructure `json:"status"`

	// Subset of a task definition
	Task Task `json:"task,omitempty"`

	// Message version
	//
	// Possible values:
	//   * 1
	Version int64 `json:"version"`
}

Message reporting that a task is now pending

type TaskRunning 

type TaskRunning struct {
	RoutingKeyKind string `mwords:"*"`
	TaskID         string `mwords:"*"`
	RunID          string `mwords:"*"`
	WorkerGroup    string `mwords:"*"`
	WorkerID       string `mwords:"*"`
	ProvisionerID  string `mwords:"*"`
	WorkerType     string `mwords:"*"`
	SchedulerID    string `mwords:"*"`
	TaskGroupID    string `mwords:"*"`
	Reserved       string `mwords:"#"`
}

Whenever a task is claimed by a worker, a run is started on the worker, and a message is posted on this exchange.

See #taskRunning

func (TaskRunning) ExchangeName 

func (binding TaskRunning) ExchangeName() string

func (TaskRunning) NewPayloadObject 

func (binding TaskRunning) NewPayloadObject() interface{}

func (TaskRunning) RoutingKey 

func (binding TaskRunning) RoutingKey() string

type TaskRunningMessage 

type TaskRunningMessage struct {

	// Id of the run that just started, always starts from 0
	//
	// Mininum:    0
	// Maximum:    1000
	RunID int64 `json:"runId"`

	// A representation of **task status** as known by the queue
	Status TaskStatusStructure `json:"status"`

	// Time at which the run expires and is resolved as `failed`, if the run
	// isn't reclaimed.
	TakenUntil tcclient.Time `json:"takenUntil"`

	// Message version
	//
	// Possible values:
	//   * 1
	Version int64 `json:"version"`

	// Identifier for the worker-group within which this run started.
	//
	// Syntax:     ^([a-zA-Z0-9-_]*)$
	// Min length: 1
	// Max length: 38
	WorkerGroup string `json:"workerGroup"`

	// Identifier for the worker executing this run.
	//
	// Syntax:     ^([a-zA-Z0-9-_]*)$
	// Min length: 1
	// Max length: 38
	WorkerID string `json:"workerId"`
}

Message reporting that a given run of a task have started

type TaskStatusStructure 

type TaskStatusStructure struct {

	// Deadline of the task, by which this task must be complete. `pending` and
	// `running` runs are resolved as **exception** if not resolved by other means
	// before the deadline. After the deadline, a task is immutable. Note,
	// deadline cannot be more than 5 days into the future
	Deadline tcclient.Time `json:"deadline"`

	// Task expiration, time at which task definition and
	// status is deleted. Notice that all artifacts for the task
	// must have an expiration that is no later than this.
	Expires tcclient.Time `json:"expires"`

	// The name for the "project" with which this task is associated.  This
	// value can be used to control permission to manipulate tasks as well as
	// for usage reporting.  Project ids are typically simple identifiers,
	// optionally in a hierarchical namespace separated by `/` characters.
	// This value defaults to `none`.
	//
	// Default:    "none"
	// Syntax:     ^([a-zA-Z0-9._/-]*)$
	// Min length: 1
	// Max length: 500
	ProjectID string `json:"projectId"`

	// Unique identifier for a provisioner, that can supply specified
	// `workerType`. Deprecation is planned for this property as it
	// will be replaced, together with `workerType`, by the new
	// identifier `taskQueueId`.
	//
	// Syntax:     ^[a-zA-Z0-9-_]{1,38}$
	ProvisionerID string `json:"provisionerId"`

	// Number of retries left for the task in case of infrastructure issues
	//
	// Mininum:    0
	// Maximum:    999
	RetriesLeft int64 `json:"retriesLeft"`

	// List of runs, ordered so that index `i` has `runId == i`
	Runs []RunInformation `json:"runs"`

	// All tasks in a task group must have the same `schedulerId`. This is used for several purposes:
	//
	// * it can represent the entity that created the task;
	// * it can limit addition of new tasks to a task group: the caller of
	//     `createTask` must have a scope related to the `schedulerId` of the task
	//     group;
	// * it controls who can manipulate tasks, again by requiring
	//     `schedulerId`-related scopes; and
	// * it appears in the routing key for Pulse messages about the task.
	//
	// Default:    "-"
	// Syntax:     ^([a-zA-Z0-9-_]*)$
	// Min length: 1
	// Max length: 38
	SchedulerID string `json:"schedulerId"`

	// State of this task. This is just an auxiliary property derived from state
	// of latests run, or `unscheduled` if none.
	//
	// Possible values:
	//   * "unscheduled"
	//   * "pending"
	//   * "running"
	//   * "completed"
	//   * "failed"
	//   * "exception"
	State string `json:"state"`

	// Identifier for a group of tasks scheduled together with this task.
	// Generally, all tasks related to a single event such as a version-control
	// push or a nightly build have the same `taskGroupId`.  This property
	// defaults to `taskId` if it isn't specified.  Tasks with `taskId` equal to
	// the `taskGroupId` are, [by convention](/docs/manual/using/task-graph),
	// decision tasks.
	//
	// Syntax:     ^[A-Za-z0-9_-]{8}[Q-T][A-Za-z0-9_-][CGKOSWaeimquy26-][A-Za-z0-9_-]{10}[AQgw]$
	TaskGroupID string `json:"taskGroupId"`

	// Unique task identifier, this is UUID encoded as
	// [URL-safe base64](http://tools.ietf.org/html/rfc4648#section-5) and
	// stripped of `=` padding.
	//
	// Syntax:     ^[A-Za-z0-9_-]{8}[Q-T][A-Za-z0-9_-][CGKOSWaeimquy26-][A-Za-z0-9_-]{10}[AQgw]$
	TaskID string `json:"taskId"`

	// Unique identifier for a task queue
	//
	// Syntax:     ^[a-zA-Z0-9-_]{1,38}/[a-z]([-a-z0-9]{0,36}[a-z0-9])?$
	TaskQueueID string `json:"taskQueueId"`

	// Unique identifier for a worker-type within a specific
	// provisioner. Deprecation is planned for this property as it will
	// be replaced, together with `provisionerId`, by the new
	// identifier `taskQueueId`.
	//
	// Syntax:     ^[a-z]([-a-z0-9]{0,36}[a-z0-9])?$
	WorkerType string `json:"workerType"`
}

A representation of **task status** as known by the queue

type Var 

type Var struct {

	// Arbitrary key-value tags (only strings limited to 4k). These can be used
	// to attach informal metadata to a task. Use this for informal tags that
	// tasks can be classified by. You can also think of strings here as
	// candidates for formal metadata. Something like
	// `purpose: 'build' || 'test'` is a good example.
	//
	// Default:    {}
	//
	// Map entries:
	// Max length: 4096
	Tags map[string]string `json:"tags"`
}

Subset of a task definition containing values that are useful for determining whether a message is interesting to the receiver. Where the full task definition is required, the receiver should call queue.task to download that definition.

Source Files

View all Source files

Jump to

Keyboard shortcuts

? : This menu
/ : Search site
f or F : Jump to
y or Y : Canonical URL
go.dev uses cookies from Google to deliver and enhance the quality of its services and to analyze traffic. Learn more.