Using its own BuildConfig when using f-m-p

[zonArt]

Is it a way to define its own BuildConfig when using f-m-p (like adding a bc.yml file in src/main/fabric8) ?

Description

Got my BuildConfig always overridden by fabric8 plugin and would really like to tune it and use it

Info

• f-m-p version : v3.5.31
• Maven version (mvn -v) : 3.3.9
• Kubernetes / OpenShift setup and version :
  openshift v1.5.1
  kubernetes v1.5.2+43a9be4
• If it's a bug, how to reproduce :
  having this kind of file in src/main/fabric8:

apiVersion: v1
kind: BuildConfig
metadata:
  name: mybuildconfig
  namespace: projectname
spec:
  source:
    binary: {}
    type: Binary
  output:
    pushSecret:
      name: artifactory
    to:
      kind: ImageStream
      name: myimagestream
  strategy:
    dockerStrategy: {}
    type: Docker
  triggers:
  - generic:
      secret: dummysecret
    type: Generic
  nodeSelector:
    kubernetes.io/hostname: hostname

It gets overridden when executing mvn fabric8:build with especially annoying removal of pushSecret because of this:

fabric8-maven-plugin/core/src/main/java/io/fabric8/maven/core/service/openshift/OpenshiftBuildService.java

Lines 179 to 182 in 9102af6

	BuildOutput buildOutput = new BuildOutputBuilder().withNewTo()
	.withKind("ImageStreamTag")
	.withName(outputImageStreamTag)
	.endTo().build();

Thank you in advance for your kind help

[FlorianBois]

I'm asking myself if the plugin is really designed to have BuildConfig and ImageStream really overridable , my understanding of the lifecycle is : build > push > resource > apply > deploy > ... However, with custom yml for BuildConfig and ImageStream , we are force to do the resource > apply before the build, which somehow do unwanted deployment (deployment done before the build) unless we do tricky workaround in the deploymentConfig

Either, the plugin is able to deal with pushSecret and make its own BuildConfig and ImageStream before the build, forbidding the custom yaml for BuildConfig and ImageStream explicitely when parameter buildRecreate = none, or either , we can provide custom BuildConfig and ImageStream but we need specifc goals for build like build-resource build-apply dedicated to the preparation of the build that do not make anything else than things related to the build.

what is the best strategy with openshift here ? this is maybe a topic for story : Fill in the gaps and decouple (https://github.com/fabric8io/fabric8-maven-plugin/projects/1 ) where openshift has a different way to do the build.

[rhuss]

Actually the build itself is considered to be an implementation detail as there are some constraints. I.e. the build has to use a binary source as this is the only mode that makes sense for an S2I build with f-m-p (where Maven runs outside s2i and the builder image just assembles the image).

Also share the concerns of @FlorianBois that it doesn't make sense to treat builds as regular resource objects.

So for now I'd recommend to extend the configuration for the plugin to tune the s2i build.

[stale]

This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!

[zonArt]

@rhuss Any news for the implementation of s2i build configuration's extend ?

[rhuss]

@zonArt no, not yet. But we are currently reworking the whole build part to allow for a more flexible way of building images. This also affects the s2i build part, and when redoing this we should add the corresponding s2i config hooks.

What's your actual use case or better, what do you want to be configurable in the build config / imagestream ?

[stale]

This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!

[rohanKanojia]

@zonArt : polite ping, Could you please elaborate your use case so that we can think about it's possible integration?

[zonArt]

Hi,

I'm not anymore working on builds with fpm for now and thus my usecase is not anymore relevant. But as far as I remember from my previous job, the need was for us to be able to configure the pushSecret within the plugin to be able to push to a private registry. Also the possibility to override the output kind would probably be great addition too (being forced to use an ImageStream is a little limitation). I think @FlorianBois would probably be the best person to answer these concerns (even if I'll follow that closely as I might need it in a next future)

[schuch]

I am also interested in this.

My use case would be to push the image to an external registry:

spec:
  output:
    to:
      kind: DockerImage   
      name: docker.io/group/imagename:latest
    pushSecret:
      name: dockerhub

See https://blog.openshift.com/pushing-application-images-to-an-external-registry/ (Step 5)

[rohanKanojia]

@schuch : Umm, you mean #1054 ??

[schuch]

Ah i overlooked that. Yes #1054 would be enough for me.

[hetzge]

I have a similar problem. I need to change the resource constraints:

spec:
  resources:
    limits:
      cpu: '1'
      memory: 1000Mi
    requests:
      cpu: 200m
      memory: 200Mi

[stale]

This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!