Automatic semver increments and sk8s tagging

[freynca]

Follow-up to #11

The sk8s-version resource (https://ci.faas.to.cf-app.com/teams/pfs/pipelines/sk8s/resources/sk8s-version) is currently manually controlled and can be bumped using the version-bump-patch and version-bump-final jobs.

The next step in sk8s build and CI is to automatically bump the version on successful builds.

See https://github.com/pivotal-cf/pfs-ci/blob/master/faas_ci_process.png

@jldec Diagram above with updated flow

[jldec]

ok, so i'm trying to map this to a workflow that other people on the team can follow.

Assuming no PR builds for now

Ci on sk8s master

• sk8s PR is reviewed
• new code is merged and committed into sk8s master
• this triggers the CI pipeline to run builds and tests for that commit
• ideally github would be notified of CI status as the builds and tests progress, and the final test status (green/red) at the end
• the container builds for the commit are pushed to dockerhub with a well defined version tag
• a versioned helm chart referencing the containers (with matching version tags) is published on our helm repo
• at some point, other artifacts (like maven) will need to be published as well

consuming artifacts

• most important for normal dev work is to be able to consume the right build containers (like the invoker base image) from the HEAD of master when doing work e.g. say on a new sample function. If an extra step is required to lookup the most recent (pushed to github) commit-triggered CI version tag, then we should make that process easy enough, so that it can be automated and included in some form in all the manual sk8s build processes. (like the main mvn package and each sample function).

• it should be also easy to figure out which version to use for ANY git commit, and helm-deploy everything from that CI build (can we use the GitHub commit status for that?)

[jldec]

@markfisher mentioned that we also need a way to use locally built images, which is what happens today by default, but then those tags also collide with images on dockerhub when the local builds are missing, which results in stale images appearing mysteriously in minikube locally (breaking the demo 😡 )

[jldec]

Hi @freynca, if you could provide a summary of how you're planning to do this, and how minikube sk8s developers will consume images built by Ci, that would be very helpful. I can't really infer this from the diagram you pointed to.

[freynca]

@jldec Updated diagram once more, to add sk8s PR step, and clarify versions and tagging.

The development process is as follows:

• A sk8s PR is submitted
  • Concourse performs a build and test using the PR pipeline (https://ci.faas.to.cf-app.com/teams/pfs/pipelines/sk8s_pr)
  • Images and Charts generated by the PR pipeline are versioned 0.0.0-pr# (example: 0.0.0-pr104, https://hub.docker.com/r/sk8s/java-function-invoker/tags/)
  • Once the PR pipeline for a given PR passes, GitHub status is updated accordingly (example: https://github.com/markfisher/sk8s/pull/104) and the PR is merged by maintainers
• Mainline builds of sk8s are run as follows
  • Pipeline: https://ci.faas.to.cf-app.com/teams/pfs/pipelines/sk8s
  • Triggered by commits to master on either the sk8s repo
  • Images and Charts generated by the mainline build are versioned by a Concourse semver (a.b.c)
  • A successful run of the mainline pipeline tags the sk8s codebase and increments the semver (example: https://github.com/markfisher/sk8s/tree/0.0.4)
• The faas-cli codebase is tagged using a dedicated semver
• Tracking tags in a working copy of sk8s: git tag --list, git describe --tags

[freynca]

Closing: https://ci.faas.to.cf-app.com/teams/pfs/pipelines/sk8s