Epic: Support background services

[kminehart]

In most CI environments, pipeline authors are able to define a list of "Services" that run in the background during the test.

Typically they are driven by docker images and are given similar (or the same) options as what's available in docker-compose.

Circle CI

In Circle CI, you are able to define docker containers to run as part of your Circle CI job. https://circleci.com/docs/2.0/configuration-reference/#docker

In Circle CI, the 'job' definition is a collection of steps that forms a 'job', the equivalent of which is a 'stage' in Drone.

Important quotes:

name defines the name for reaching the secondary service containers. By default, all services are exposed directly on localhost. The field is appropriate if you would rather have a different host name instead of localhost, for example, if you are starting multiple versions of the same service.

Drone

In Drone, Services are a little bit more striaghtforward as they are a higher-order object / array in the yaml.

Example (from: https://docs.drone.io/pipeline/docker/syntax/services/)

kind: pipeline
type: docker
name: default

steps:
- name: ping
  image: redis
  commands:
  - redis-cli -h cache ping

services:
- name: cache
  image: redis

According to that same document, services can be defined in a pipeline the same way a normal step is, but with the detached: true flag set, allowing services to start later in the pipeline.

Poposal

In a pipeline

I think in a pipeline we can make the service the same as a normal step but with some extra metadata associated. That way Clients don't have to go out of their way to explicitly handle services.

package main

var Redis = pipeline.NamedStep("redis", pipeline.DefaultAction).WithImage("redis:9")

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

        sw.Service(Redis)

        sw.Run(...)

        sw.Parallel(...)
}

I think this gives us a basic enough type to work with and we can expand it in the future. The name 'Service' is not too great since there's both a noun and a verb version. I think a better alternative might be 'Background'? It's more self-descriptive.

Clients

One other component of this addition is that each client will have a different way to manage background services.

• The Docker client will have to start/stop the containers when the pipeline starts/stops.
• The CLI client may not reasonably be able to support this unless we run the services in Docker using the docker command (or the Docker Go client).
• The Drone client will have to render the services in the generated Drone YAML, meaning they need to be available when Done(...) is called.

Pre-requesites:

• [Docker] Every container should run in the same docker network for a single execution #26