Using a simple documented BuildConfig
, we're seeing every newly created BuildConfig resource defaulting failedBuildsHistoryLimit and successfulBuildsHistoryLimit when documentation specifies BuildConfig not having default values and honoring preserving all builds.
i'm assuming you're basing your statement on the api doc:
(if you saw it somewhere else, please let us know).
Unfortunately that doc is wrong... when we moved from legacy resource types to grouped resource types, we introduced a default retention of 5 for each type(successful and failed). If you created a buildconfig via the legacy resource you got no limit, but if you create it via the grouped resource (which is the default and what everyone should be doing now), you got a default of 5 applied to your object. If you look at the buildconfig.yaml (oc get bc/foo -o yaml) you will see that value appear because it's actually applied to your object during creation.
you can edit the bc and delete the field to switch to no retention, or you can create your BCs with a very high retention. I don't think you can actually create a BC w/ no retention limit, though, given how the system works.
My knee jerk thought was to talk with my OCP administrators to see whether nodes were configured to default aspects of specific resource types, however we didn't see anything readily within master-config.yaml file on one of the masters.
Any assistance is appreciated!
me me-mbp ~ $ oc version
me me-mbp ~ $ oc new-project ruby-sample
me me-mbp ~ $ cat << EOF | oc apply -f - -n ruby-sample
> kind: "BuildConfig"
> apiVersion: "v1"
> name: "ruby-sample-build"
> runPolicy: "Serial"
> triggers: 
> uri: "https://github.com/openshift/ruby-hello-world"
> kind: "ImageStreamTag"
> name: "ruby-20-centos7:latest"
me me-mbp ~ $ oc get -o yaml bc ruby-sample-build
Andy Feller • Sr DevOps Engineer
900 Main Campus Drive, Suite 500, Raleigh, NC 27606
e: afeller bandwidth com
users mailing list
users lists openshift redhat com