Skip to content
This repository has been archived by the owner on Oct 3, 2023. It is now read-only.

Allow pipeline developers to define the event that will cause their pipeline to run. #27

Closed
kminehart opened this issue Mar 22, 2022 · 0 comments

Comments

@kminehart
Copy link
Collaborator

kminehart commented Mar 22, 2022

Background

The CI process is a sequence of actions that happen as the result of an event. In the vast majority of cases, these events are sent by an SCM like GitHub or GitLab. In some cases, however, these events can come from many different sources.

Because different systems may or may not support specific events, the events which we are able to provide in the Shipwright library will be very limited to the

Some examples of possible sources we will want to consider:

  • Manually triggered actions, like Promotions in Drone. In some systems, which we may not currently have implemented, this could represent a webhook or an API endpoint.

Events

In Shipwright, Events are a way to filter when a pipeline will run in an external system. Assuming that the external system receives all possible events, like commits, tags, pull requests, etc, then defining Events in your pipeline will apply filters on those events.

Events can also provide variables in the pipeline. Examples:

  • The commit event can provide the commit hash and branch.
  • The 'manual' event can provide any map of keys/values.
  • The 'tag' event can provide a commit hash and name but not a branch.

In Drone

In Drone, for example, users can supply the triggers object.

https://docs.drone.io/pipeline/triggers/

Their first example shows a pipeline that will only run on the main branch.

kind: pipeline
type: docker
name: default

steps:
- name: build
  image: golang
  commands:
  - go build
  - go test

trigger:
  branch:
  - main

In Shipwright

Requirements

  • Pipeline developers should be able to define new events. The Shipwright packages should have premade events.
  • Events must be able to define what values they are able to be filtered on. For example, the NewEventCommit should say that it can be filtered by branch name.
  • Events, their filters, and arguments must be able to be introspected by individual clients.
  • Events must be able to define what values they provide.

Implementation

Events

Every pipeline is submitted with

A general pipeline.Event holds:

  • The filters that this event holds.
  • The arguments that event provides.

Each individual implementation of a Shipwright client will have to figure out:

  • What events it can receive.
  • Converting the pipeline event into the pipeline state.

Something like this:

type Event struct {
    Filters    map[string]string
    Provides []pipeline.Argument
}

Creating a new event

In this example, we create an event to be used in Shipwright pipelines.

var EventGitCommit = pipeline.NewEvent(
    pipeline.ArgumentGitCommit,
    pipeline.ArgumentGitBranch,
)

Using a pre-defined pipeline event

This event, CommitEvent, is predefined by the Shipwright packages.

var commitEvent = pipeline.NewCommitEvent(pipeline.CommitFilters{
    Branch: "main",
})

We can supply a list of events for pipeline after creating shipwright.New.

package main

func main() {
	sw := shipwright.New("basic pipeline")

	defer sw.Done()

	sw.Run(...)
}
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant