kesselborn / jindra Goto Github PK

meaning: write a pipeline for jindra itself and deploy it

pod should not be deleted by job though

save them in /opt/resource/transit/.jindra/<stage>/logs/<container>.log

• store new pipeline config in k8s
  • update, don’t delete and create due to ownership references
  • copy Status
• update check cron jobs
  • copy version annotation

delete files, which are not in the out resource ... if files should survive more than one stage, it's necessary to use transit as input and output resource

A pipeline run should be triggered, if an event gets created.

Event structure: tbd

validating:

• trigger resource only allowed on first stage
• disallow duplicate input/output resource names in annotation
• disallow duplicate resource naming
• only allow existent resource names in resource annotations
• check that services annotation container exists
• no owner references in stages pod specs
• restart policy not set or set to never

modifying:

• set default names for onSuccess, onError, onFinal

integration test:

• for modifying webhook
• for validating webhook
• for validating a pod via pod validation
• updating pipeline, check that status remains

https://book.kubebuilder.io/cronjob-tutorial/controller-implementation.html#4-check-if-were-suspended

https://book-v1.book.kubebuilder.io/beyond_basics/generating_crd.html

playground aint good

• update status before build ist startet
  • take jindra.io/build-no-offset: "42" into account

(tbd) from Concourse: https://concourse-ci.org/implementing-resource-types.html#resource-metadata

• $BUILD_ID
  The internal identifier for the build. Right now this is numeric but it may become a guid in the future. Treat it as an absolute reference to the build.
• $BUILD_NAME
  The build number within the build's job.
• $BUILD_JOB_NAME
  The name of the build's job.
• $BUILD_PIPELINE_NAME
  The pipeline that the build's job lives in.
• $BUILD_TEAM_NAME
  The team that the build belongs to.
• $ATC_EXTERNAL_URL
  The public URL for your ATC; useful for debugging.

• create secret object
• write tests

• the name doesn't reflect what it does
• the options are not well named
• it does not belong in the playground folder

with error / info / debug level ... configurable

• namespaces as array or cluster (== *?)

Go tool like crij that looks after semaphores

https://book.kubebuilder.io/cronjob-tutorial/controller-implementation.html#3-clean-up-old-jobs-according-to-the-history-limit

so logs can be placed there from the runner
note: must be done before on-success, on-error, final container

• create job object
  • make pipeline the owner
• test correctness

• create kubernetes object
  • make pipeline the owner
• test kubernetes object
• create on pipeline creation
• update on pipeline destruction

So they make changes don’t break runner

... use go generate

• implement
• create integration test

• create service account, role, rolebinding
  • permissions for k8s-pod-status
  • permissions to create and delete pods with dedicated names (possible?)
• let runner own sa, role, rolebinding

by using kind and setting all jindra-generated containers imagePullPolicy: IfNotPresent

this way, we can pass data, that is only available during run (git commit, etc.)

• extend crij: add parameter for allowing env file
• add annotation for resources where you can define, where the env file lies
• delete env file after reading (to keep resource directory clean)

and between tools-setup and resource init containers ... or should this be configurable 🧐? ... via annotation?

• do it
• test it
• document it

save them in resource folder under .resource-stdout and .resource-stderr

even if other containers fail (apart from init containers)

... using kind (kubernetes in docker)

• start pipeline, create a file in stage 1 & stage 2, copy files from transit to local filesystem and check whether all files are there with correct content