2.10 Golang library testing example
You can run the tests for a Golang library across any specified versions.
This example shows how to have multiple versions of a language, environment, or dependency fetched and integrated in to a Pipeline.
For these Docker images, defining them as Resources has two advantages for this use case. First, this enables the pipeline to be triggered when there are new versions of those images available. Second, referencing them in the task's task
step image
param is helpful as it will ensure consistency between the image versions fetched by the Resource and the image version running in the job.
Pipeline Configuration
---
resources:
- name: golang-1.20.x-image
type: registry-image
icon: docker
source:
repository: golang
tag: 1.20-alpine
- name: golang-1.21.x-image
type: registry-image
icon: docker
source:
repository: golang
tag: 1.21-alpine
- name: golang-1.22.x-image
type: registry-image
icon: docker
source:
repository: golang
tag: 1.22-alpine
task-config: &task-config
platform: linux
run:
path: /bin/sh
args:
- -c
- |
GOPATH=$PWD/go
go version
jobs:
- name: golang-1.20
public: true
plan:
- get: golang-1.20.x-image
trigger: true
- task: run-tests
image: golang-1.20.x-image
config:
<< : *task-config
- name: golang-1.21
public: true
plan:
- get: golang-1.21.x-image
trigger: true
- task: run-tests
image: golang-1.21.x-image
config:
<< : *task-config
- name: golang-1.22
public: true
plan:
- get: golang-1.22.x-image
trigger: true
- task: run-tests
image: golang-1.22.x-image
config:
<< : *task-config