Task Details - michaelsauter/ods-pipeline GitHub Wiki

Information on each task will be available at a later stage once the tasks have been implemented.

ods-start

Requirements

  1. Clone repository at revision
  2. Read ODS config and clone child repositories
  3. For each repository, store repo related information under .ods/
  4. Set Bitbucket build status to "in progress"
  5. Set task results (which ones exactly?)

ods-finish

Requirements

  1. Set Bitbucket build status to "failed" or "successful"
  2. Notification (what exactly? e.g. Teams channel?)

ods-build-go

Requirements

  1. Build Go module based Go binary
  2. Run golanglint-ci
  3. Run go test, creating code coverage and xUnit report
  4. Run sonar-scanner on branch
  5. Run sonar-scanner with PR analysis
  6. Allow to run a Make target instead of 1,2,3
  7. Publish results to Nexus (test results, Sonar scan)

Validation

  1. Build Go module based Go binary
  • Source code (including 3rd party module) is transformed into executable binary
  • Build errors stop the task
  1. Run golanglint-ci
  • Linting errors stop the task
  1. Run go test, creating code coverage and xUnit report
  • Test error stop the task
  • Code coverage report exists
  • xUnit report exists and contains specified tests
  1. Run sonar-scanner on branch
  • ...

ods-build-image

Requirements

  1. Build image based on Dockerfile
  2. Scan image with Aqua scanner
  3. Push image to registry
  4. Publish results to Nexus (Image details, Aqua scan)

ods-deploy-helm

This tasks depends on the workspace.

It has two main functions:

  • Push images into the release namespace
  • Upgrade the Helm release in the release namespace

It reads ods.yml from the root of the workspace.

It figures out the release namespace based on given branch / version.

It reads built images from Nexus.

It pushes each built image from the *-cd namespace to the release namespace with Skopeo.

It errors if there is no chart at the configured chartDir.

It assumes that one repository is equal to one deployment unit (= has one chart).

It packages charts using the version in the YAML and the Git SHA identifier as build meta data (for lack of better options ... precedence does not matter for us). The packaged charts are uploaded to Nexus. Packaging charts has the advantage that they can be signed, shared with other processes and that the appVersion/version can be set properly to the Git commit SHA.

If child repositories are configured, it looks for any packaged charts in Nexus and puts them into chartDir/charts. Open question: what happens when a race occurs and the umbrella pipeline reaches this point before the charts were packaged? Maybe best to check that the commits in use by the umbrella pipeline already have a recorded run in Nexus. If not, require to re-run that repo's pipeline.

For monorepos, it is assumed that the chart resources for all components in the repo are inside the chartDir already.

It automatically discovers value files based on the following logic:

  • values.yml if present
  • values/ENV.yml (e.g. values/dev.yml) if present
  • values/ENV-DESTINATION.yml (e.g. values/dev-default.yml) if present

A downside of using an umbrella chart is that the pipeline task config of the individual repos is ignored - e.g. any values overwrites would not be applied (maybe we should not allow value overwriting at all?).

Potentially add linting of chart (with potential failure?)