Labelling Openshift Build transient pods - docker

I have a simple S2I build running on an Openshift 3.11 project that outputs to an Image Stream.
The build is working fine, the resulting images are tagged correctly and available in the stream. My issue is, each build spins up a transient pod to handle doing the actual build. I would like to label these pods. This project is shared between multiple teams and we have several scripts that differentiate pods based on a label.
Right now each one automatically gets labelled like so:
openshift.io/build.name: <buildname>-<buildnum>
Which is fine, I don't want to get rid of that label. I just want to add an additional custom label (something like owner: <teamname>). How can I do that?

You can add your custom label using imageLabels section in the buildConfig as follows. Further information is here, Output Image Labels.
spec:
output:
to:
kind: "ImageStreamTag"
name: "your-image:latest"
imageLabels:
- name: "owner"
value: "yourteamname"

Related

How to define component/step using training operators such as TFJob in kubeflow pipeline

I know there is a way to use tfjob operator via kubectl, like the example at here (https://www.kubeflow.org/docs/components/training/tftraining/):
kubectl create -f https://raw.githubusercontent.com/kubeflow/training-operator/master/examples/tensorflow/simple.yaml
But I don't know how to incorporate in kubeflow pipeline. A normal component/job is defined via #component decoration or ContainerOp is a Kubernetes Job kind which runs in a Pod, but I don't know how to define a component with special training operator such as TFJob, so that my code runs as
apiVersion: "kubeflow.org/v1"
kind: TFJob
rather than:
apiVersion: "kubeflow.org/v1"
kind: Job
in kubernetes.
P.S.: there is a example here: https://github.com/kubeflow/pipelines/blob/master/components/kubeflow/launcher/sample.py
but don't see anywhere specify TFJob
The example you reference leverages some code that actually creates a TFJob (look at the folder of your example):
TFJob is instantiated here: https://github.com/kubeflow/pipelines/blob/master/components/kubeflow/launcher/src/launch_tfjob.py#L97
...and created as Kubernetes resource here: https://github.com/kubeflow/pipelines/blob/master/components/kubeflow/launcher/src/launch_tfjob.py#L126
...the previous code is accessed by a Kubeflow component as specified here: https://github.com/kubeflow/pipelines/blob/master/components/kubeflow/launcher/component.yaml
...which is imported into your referenced example here: https://github.com/kubeflow/pipelines/blob/master/components/kubeflow/launcher/sample.py#L60
The general question you raised is still subject to current discussions. Using tfjob_launcher_op appears to be the currently recommended way. Instead, some people also natively use ResourceOps to simulate your kubectl create call.

In jenkins-kubernetes-plugin, how to generate labels in Pod template that are based on a pattern

Set-Up
I am using jenkins-kubernetes-plugin to run our QE jobs. The QE jobs are executed over multiple PODs and each POD has a static set of labels like testing chrome
Issue:
In these QE jobs, there is one port say 7900 that I want to expose through Kubernetes Ingress Controller.
The issue is we have multiple PODs running from the same Pod Template and they all have the same set of labels. For Ingress Controller to work, I want these PODs to have some labels that come from a pattern.
Like POD1 has a label chrome-1 and POD2 has a label called chrome-2 and so on...
Is this possible?
This is not currently possible directly, but you could use groovy in the pipeline to customize it, ie. add the build id as a label

Bazel Monorepo - How Rebuild and Publish only Changed Docker Images?

Objective
I have a monorepo setup with a growing number of services services. When I deploy the application I run a command and every service will be rebuilt and the final Docker images will be published.
But as the number of services grows the time it takes to rebuilt all of them gets longer and longer, although changes were made to only a few of them.
Why does my setup rebuilt all Docker images although only a few have changed? My goal is to rebuilt and publish only the images that have actually changed.
Details
I am using Bazel to build my Docker images, thus in the root of my project there is one BUILD file which contains the target I run when I want to deploy. It is just a collection of k8s_objects, where every service is included:
load("#io_bazel_rules_k8s//k8s:objects.bzl", "k8s_objects")
k8s_objects(
name = "kubernetes_deployment",
objects = [
"//services/service1",
"//services/service2",
"//services/service3",
"//services/service4",
# ...
]
)
Likewise there is one BUILD file for every service which first creates a Typescript library from all the source files, then creates the Node.Js image and finally passes the image to the Kubernetes object:
load("#npm_bazel_typescript//:index.bzl", "ts_library")
ts_library(
name = "lib",
srcs = glob(
include = ["**/*.ts"],
exclude = ["**/*.spec.ts"]
),
deps = [
"//packages/package1",
"//packages/package2",
"//packages/package3",
],
)
load("#io_bazel_rules_docker//nodejs:image.bzl", "nodejs_image")
nodejs_image(
name = "image",
data = [":lib", "//:package.json"],
entry_point = ":index.ts",
)
load("#k8s_deploy//:defaults.bzl", "k8s_deploy")
k8s_object(
name = "service",
template = ":service.yaml",
kind = "deployment",
cluster = "my-cluster"
images = {
"gcr.io/project/service:latest": ":image"
},
)
Note that the Typescript lib also depends on some packages, which should also be accounted for when redeploying!
To deploy I run bazel run :kubernetes_deployment.apply
Initially one reason I decided to choose Bazel is because I thought it would handle building only changed services itself. But obviously this is either not the case or my setup is faulty in some way.
If you need more detailed insight into the project you can check it out here: https://github.com/flolude/cents-ideas
Looks like Bazel repo itself does something similar:
https://github.com/bazelbuild/bazel/blob/ef0f8e61b5d3a139016c53bf04361a8e9a09e9ab/scripts/ci/ci.sh
The rough steps are:
Calculate the list of files that has changed
Use the file list and find their dependents (e.g. The bazel querykind(.*_binary, rdeps(//..., set(file1.txt file2.txt))) will find all binary targets which are dependents of either file1.txt or file2.txt)
build/test the list of targets
You will need to adapt this script to your need (e.g. make sure it finds docker image targets)
To find out the kind of a target, you can use bazel query //... --output label_kind
EDIT:
A bit of warning for anyone who wants to go down this rabbit hole (especially if you absolutely do not want to miss tests in CI):
You need to think about:
Deleted files / BUILD files (who depended on them)
Note that moved files == Deleted + Added as well
Also you cannot query reverse deps of files/BUILD that doesn't exist anymore!
Modified BUILD files (To be safe, make sure all reverse deps of all targets in the BUILD are built)
I think there is a ton of complexity here going down this route (if even possible). It might be less erro-prone to rely on Bazel itself to figure out what changed, using remote caches & --subcommands to calculate which side-effects need to be performed.

Customize Jenkins pipeline stage view

How can i add the little blue tags to stage view in a Jenkins Pipeline?
I was searching for this as well and found the following after reading Hatim's answer:
The line that was supposed to show the node label is commented out:
source
The referenced issue JENKINS-33290 is Resolved with the last comment:
Resolved by removing the functionality, since a correct implementation imposes unacceptable complexity and overhead.
So I'm afraid it's not coming back soon and all those screenshots online are outdated.
Is the name or label of the node used.
Please refer to this
https://jenkins.io/doc/pipeline/steps/workflow-durable-task-step/
node: Allocate node
Allocates an executor on a node (typically a slave) and runs further code in the context of a workspace on that slave.
label
Computer name, label name, or any other label expression like linux && 64bit to restrict where this step builds. May be left blank, in which case any available executor is taken.
In this case, the stage is executed in the master, if you configure your jenkins pipeline to be executed in differents plateforms (master-slaves), then you will be able to see the label of your slaves environement.

How can I select some projects to be eligible to be built by slaves

I've created successfully my 1st Jenkins slave, but I don't want to be used to all the projects, so I've chosen the {{Only selected projects}} option.
But how can I choose the projects?
I've looked at Jenkins management, and the configuration of a project, and I don't see the needed setting.
You tie jobs to slaves in the jobs' configuration: go to ${jenkins url}/job/${job name}/configure and look for the Restrict where this project can be run field in the general settings:
You can type names of slaves there, or even better, use tags assigned to slaves. You can use logical expressions like || and &&, too.
To expand on ameba's answer you can set labels for a node in the node configuration settings and therefore label nodes with the toolchains or tools that you require.
Then in jenkins-pipeline you can do the following:
node('TOOL label')
{
stage('build using TOOL') {
}
}
the node section tell jenkins to find a node with that label and to use it for the following block of code.

Resources