1
0
mirror of https://github.com/tektoncd/catalog.git synced 2024-11-22 06:02:51 +00:00
catalog/task/generate-build-id/0.1
Shivam Mukhade a17a8cf3d4 Modifies generate-build-id task according to the new reorg proposal
Changes include:
  - adds version label
  - adds a minimum pipeline versions supported by the task
  - adds display name for task
  - adds tags for task
  - modified description to add a summary

This patch moves the buildid files to the task directory and
renames the yaml file
  - The yaml filename and directory name is changed to match the resource name.

Issue: #386

Signed-off-by: Shivam Mukhade <smukhade@redhat.com>
2020-07-10 22:06:57 +01:00
..
examples Modifies generate-build-id task according to the new reorg proposal 2020-07-10 22:06:57 +01:00
tests Modifies generate-build-id task according to the new reorg proposal 2020-07-10 22:06:57 +01:00
generate-build-id.yaml Modifies generate-build-id task according to the new reorg proposal 2020-07-10 22:06:57 +01:00
OWNERS Modifies generate-build-id task according to the new reorg proposal 2020-07-10 22:06:57 +01:00
README.md Modifies generate-build-id task according to the new reorg proposal 2020-07-10 22:06:57 +01:00

buildid

Given a base version, this task generates a unique build id by appending the base-version to the current timestamp.

Install the Task

kubectl apply -f https://raw.githubusercontent.com/tektoncd/catalog/master/buildid/task.yaml

Parameters

  • base-version: The base version to use in the generated build id. default: ["1.0"]

Usage

Include the task inside a taskrun

In this example, we will demonstrate how to use the task to generate the build id by including it in a taskrun definition called taskrun.yaml:

apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
  name: generate-build-id-run
spec:
  params:
    - name: base-version
      value: "2.3.1"
  taskRef:
    name: generate-build-id

As can be seen from the example, the default base-version is being overridden by providing a new base-version value of 2.3.1 as input param to the task.

The taskrun definition is then applied by installing it in Kubernetes cluster as kubectl apply -f taskrun.yaml. Logs from the executed task are then retrieved using tkn taskrun logs generate-build-id-run:

#\> tkn taskrun logs generate-build-id-run
[get-timestamp] Current Timestamp: 20200617-180133
[get-timestamp] 20200617-180133

[get-buildid] 2.3.1-20200617-180133

Use the generated build id in another task in a pipeline definition

In this example, we will demonstrate how the generated build id can be used by another task by including them inside a pipeline definition.

In the following example two tasks are included in a pipeline definition called pipeline.yaml

apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: pipeline-demo-generated-build-id
spec:
  params:
    - name: service-version
      type: string
      default: "3.1.1"
  tasks:
    - name: get-build-id
      taskRef:
        name: generate-build-id
      params:  
        - name: base-version
          value: $(params.service-version)       
    - name: build-api
      taskRef:
        name: build-service-api
      params:
        - name: build-id
          value: "$(tasks.get-build-id.results.build-id)"

As can be seen from the example the first task generates the build id while the second task consumes the generated build id. In the task to generate the build id, we override the default value of base-version using the value of the service-version pipeline parameter that has currentluy been set to a default value of 3.1.1. In the task to build the service api, we then pass the generated build from the first task as its input param called build-id. For the sake of completeness, here is what the task to build the service api (build-service-api.yaml) looks like:

apiVersion: tekton.dev/v1betal
kind: Task
metadata:
  name: build-service-api
spec:
  params:
    - name: build-id
      description: ID of the current build
      type: string                          
  steps:
    - name: display-buildid
      image: bash:latest
      script: |
        #!/usr/bin/env bash
        echo "Provided Build ID: $(inputs.params.build-id)"

As can be seen above, this task accepts a build id as its input and displays it in its one and only step.

The task to build the service api and pipeline are then installed using kubectl apply -f build-service-api.yaml and kubectl apply -f pipeline.yaml. Once installed the pipeline is started using tkn pipeline start pipeline-demo-generated-build-id. Logs from the executed pipeline demonstrate that the first task generated a build id while the second task consumed it:

#\> tkn pipeline start pipeline-demo-generated-build-id
? Value for param `service-version` of type `string`? (Default is `3.1.1`) 3.1.1
Pipelinerun started: pipeline-demo-generated-build-id-run-g7tgw

In order to track the pipelinerun progress run:
tkn pipelinerun logs pipeline-demo-generated-build-id-run-g7tgw -f -n default

#\> tkn pipelinerun logs pipeline-demo-generated-build-id-run-g7tgw
[get-build-id : get-timestamp] Current Timestamp: 20200617-181338
[get-build-id : get-timestamp] 20200617-181338

[get-build-id : get-buildid] 3.1.1-20200617-181338

[build-api : display-buildid] Provided Build ID: 3.1.1-20200617-181338