Jx: The command "jx edit buildpack" does nothing

[hervelemeur]

Summary

Following our Slack discussion, I've tried to configure jenkins-x with custom buildpacks, but it didn't work, no change at all.

$ jx edit buildpack -u https://github.com/my-org/jenkins-x-kubernetes
? Defaulting workload build pack: Kubernetes Workloads: Automated CI+CD with GitOps Promotion
Setting the team build pack to kubernetes-workloads repo: https://github.com/jenkins-x-buildpacks/jenkins-x-kubernetes.git ref: master

Steps to reproduce the behavior

• fork the jenkins-x-kubernetes buildpack repository
• execute this command:

$ jx edit buildpack -u https://github.com/my-org/jenkins-x-kubernetes

Expected behavior

JX is configured to use the custom buildpacks, and this configuration is saved in the jx boot dev repository.

Actual behavior

Nothing happens.

Jx version

The output of jx version is:

NAME               VERSION
jx                 2.0.1284
Kubernetes cluster v1.15.7
kubectl            v1.17.3
helm client        2.16.3
git                2.21.1 (Apple Git-122.3)
Operating System   Mac OS X 10.15.3 build 19D76

Kubernetes cluster

AKS cluster, manually created.

@vfarcic FYI
Relate to https://github.com/jenkins-x/jx/issues/6374

[frankvollenweider]

I'm trying to change the buildpacks for my Jenkins-x installation with the command 'jx edit buildpack -u', but unfortunately I'm also getting the error mentioned in the issue summary. Is there another way I can change the buildpacks?

My environment:
jx 2.1.13+cjxd.9
Kubernetes cluster v1.14.10-gke.27
kubectl v1.13.2
helm client 2.12.2
git 2.17.1
Operating System Ubuntu 18.04.4 LTS

[mrageh]

I'm working on a fix for this and will have it out by next week. I missed your question in my notifications @frankvollenweider

[hferentschik]

So the problem is the following. Currently the information about the build pack location (repository URL + ref) are stored in TeamSettings as part of the Environment CRD:

type TeamSettings struct {
    BuildPackURL        string               `json:"buildPackUrl,omitempty" protobuf:"bytes,6,opt,name=buildPackUrl"`
    BuildPackRef        string               `json:"buildPackRef,omitempty" protobuf:"bytes,7,opt,name=buildPackRef"`
    BuildPackName       string               `json:"buildPackName,omitempty" protobuf:"bytes,20,opt,name=buildPackName"`
...

This is also what jx edit buildpack edits.

With the introduction of jx boot this is not working anymore. There are a couple of reasons for that. First of all, there is no way to configure the build pack location in jx-requirements.yaml yet and more importantly each time the boot pipeline runs, the TeamSettings get overridden. This is due to the fact that we are applying the jxboot-resources Helm Chart as part of the boot config - https://github.com/jenkins-x/jenkins-x-boot-config/tree/master/env/jxboot-resources. This Chart contains also values for the TeamSettings:

• https://github.com/jenkins-x-charts/jxboot-resources/blob/master/jxboot-resources/values.yaml#L43-L45
• https://github.com/jenkins-x-charts/jxboot-resources/blob/master/jxboot-resources/templates/dev-env.yaml#L22

Given that the boot config does not configure these settings it means each time boot runs the values would be overwritten with the defaults.

To remedy this we need to add the required parameters to RequirementsConfig so that this cave be configured via jx-requiremnts.yaml. Apart from changing RequirementsConfig we would need to update _jenkins-x-boot-config_ to take care of these new configuration options and applying them to the jxboot-resources.

That said, the naming of these properties is bad, since we are effectively not changing/editing a given build pack, but we are changing the "build pack lookup location". This should be taken into account when changing RequirementsConfig . For example (naming open for discussion):

bootConfigURL: https://github.com/jenkins-x/jenkins-x-boot-config.git
buildPacks:
   location:
      name:
      gitURL:
      gitRef:
cluster:
...

So I am suggesting a 'buildPacks' entry to group all build pack related config (there might be more further down the road) as well as a 'location' entry to group the three relevant properties for the location.

Not sure whether the whole 'buildPacks' entry should maybe move under the _dev_ environment since it is at least for now tied to an Environment as well. This would allow having different locations based for different environments. Otherwise, we have one global setting for it.

Last but not least, as part of this work, jx edit buildpack should be removed or at least deprecated.

[hferentschik]

Note, trying to rectify some of the namings around this in the requirements does not mean we necessarily have to rename things in the jxboot-resources Chart or the TeamSettings. Especially changing the latter is not trivial w/0 breaking things.

[dgozalo]

Not sure whether the whole 'buildPacks' entry should maybe move under the dev environment since it is at least for now tied to an Environment as well. This would allow having different locations based for different environments. Otherwise, we have one global setting for it.

While it's in the TeamSettings of the dev environment, it's not really tied to an environment, because you will never configure a BuildPack location in staging or production. Dev is just the place we've chosen to put all the configuration into.

So I'm fine with it being left out of Environment within jx-requirements.

[hervelemeur]

Thanks for the explaination @hferentschik !

Agreed with @dgozalo, your current suggestion (buildpacks config placed at top level) seems fine since it's a global configuration, and doesn't really concern a particular environment.

[hferentschik]

Agreed with @dgozalo, your current suggestion (buildpacks config placed at top level) seems fine since it's a global configuration, and doesn't really concern a particular environment.

Kind of, to a certain degree we already painted ourselves into a corner by treating each environment equal in the configuration. Conceptually there is a huge difference between the dev/configuration environment and the staging/production (deployment) environment. So yes, right now if we were to add the build pack config under environment, we would end up with the strange situation that one could add this configuration to the staging or production environment which would make no sense.

At the same time, I think a cluster can potentially support multiple dev environments, each potentially with their own build packs. We cannot model this by adding the config to the root of the requirements config.

So really it becomes a trade-off between what has the lesser negative impacts. I am also inclined to say that adding the config to the root makes more sense.

[hferentschik]

So one thing we have not been taking into account is that there is actually also the concept of a BuildPack CRD. In fact the _jenkins-x-platform_ Chart does have values for these - https://github.com/jenkins-x/jenkins-x-platform/blob/master/jenkins-x-platform/values.yaml#L15 and https://github.com/jenkins-x/jenkins-x-platform/blob/master/jenkins-x-platform/templates/buildpacks.yaml#L1

The intend was probably to create a set of BuildPacks and via jx edit buildpack one could select on of the existing one which got "persisted" into TeamSettings of the Environment. With Boot it really does not work like this anymore and there is a single persisted build pack library configured in TeamSettings. There is no use for multiple BuildPack CRDs. Probably best to ignore for now.

[hervelemeur]

See this comment: https://github.com/jenkins-x/jx/issues/6303#issuecomment-630213155

There is apparently already a way to configure this in dev repository.

The jx edit buildpack -u ... command is still not working with boot though.