Class BuildConfig

  • All Implemented Interfaces:
    io.fabric8.kubernetes.api.builder.Editable<BuildConfigBuilder>, io.fabric8.kubernetes.api.model.HasMetadata, io.fabric8.kubernetes.api.model.KubernetesResource, io.fabric8.kubernetes.api.model.Namespaced, Serializable

    @Generated("io.fabric8.kubernetes.schema.generator.model.ModelGenerator")
    public class BuildConfig
    extends Object
    implements io.fabric8.kubernetes.api.builder.Editable<BuildConfigBuilder>, io.fabric8.kubernetes.api.model.HasMetadata, io.fabric8.kubernetes.api.model.Namespaced
    Build configurations define a build process for new container images. There are three types of builds possible - a container image build using a Dockerfile, a Source-to-Image build that uses a specially prepared base image that accepts source code that it can make runnable, and a custom build that can run // arbitrary container images as a base and accept the build parameters. Builds run on the cluster and on completion are pushed to the container image registry specified in the "output" section. A build can be triggered via a webhook, when the base image changes, or when a user manually requests a new build be // created.


    Each build created by a build configuration is numbered and refers back to its parent configuration. Multiple builds can be triggered at once. Builds that do not have "output" set can be used to test code or run a verification build.


    Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer).

    See Also:
    Serialized Form
    • Constructor Detail

      • BuildConfig

        public BuildConfig()
        No args constructor for use in serialization
    • Method Detail

      • getApiVersion

        public String getApiVersion()
        APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources
        Specified by:
        getApiVersion in interface io.fabric8.kubernetes.api.model.HasMetadata
      • setApiVersion

        public void setApiVersion​(String apiVersion)
        APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources
        Specified by:
        setApiVersion in interface io.fabric8.kubernetes.api.model.HasMetadata
      • getKind

        public String getKind()
        Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
        Specified by:
        getKind in interface io.fabric8.kubernetes.api.model.HasMetadata
      • setKind

        public void setKind​(String kind)
        Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
      • getMetadata

        public io.fabric8.kubernetes.api.model.ObjectMeta getMetadata()
        Build configurations define a build process for new container images. There are three types of builds possible - a container image build using a Dockerfile, a Source-to-Image build that uses a specially prepared base image that accepts source code that it can make runnable, and a custom build that can run // arbitrary container images as a base and accept the build parameters. Builds run on the cluster and on completion are pushed to the container image registry specified in the "output" section. A build can be triggered via a webhook, when the base image changes, or when a user manually requests a new build be // created.


        Each build created by a build configuration is numbered and refers back to its parent configuration. Multiple builds can be triggered at once. Builds that do not have "output" set can be used to test code or run a verification build.


        Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer).

        Specified by:
        getMetadata in interface io.fabric8.kubernetes.api.model.HasMetadata
      • setMetadata

        public void setMetadata​(io.fabric8.kubernetes.api.model.ObjectMeta metadata)
        Build configurations define a build process for new container images. There are three types of builds possible - a container image build using a Dockerfile, a Source-to-Image build that uses a specially prepared base image that accepts source code that it can make runnable, and a custom build that can run // arbitrary container images as a base and accept the build parameters. Builds run on the cluster and on completion are pushed to the container image registry specified in the "output" section. A build can be triggered via a webhook, when the base image changes, or when a user manually requests a new build be // created.


        Each build created by a build configuration is numbered and refers back to its parent configuration. Multiple builds can be triggered at once. Builds that do not have "output" set can be used to test code or run a verification build.


        Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer).

        Specified by:
        setMetadata in interface io.fabric8.kubernetes.api.model.HasMetadata
      • getSpec

        public BuildConfigSpec getSpec()
        Build configurations define a build process for new container images. There are three types of builds possible - a container image build using a Dockerfile, a Source-to-Image build that uses a specially prepared base image that accepts source code that it can make runnable, and a custom build that can run // arbitrary container images as a base and accept the build parameters. Builds run on the cluster and on completion are pushed to the container image registry specified in the "output" section. A build can be triggered via a webhook, when the base image changes, or when a user manually requests a new build be // created.


        Each build created by a build configuration is numbered and refers back to its parent configuration. Multiple builds can be triggered at once. Builds that do not have "output" set can be used to test code or run a verification build.


        Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer).

      • setSpec

        public void setSpec​(BuildConfigSpec spec)
        Build configurations define a build process for new container images. There are three types of builds possible - a container image build using a Dockerfile, a Source-to-Image build that uses a specially prepared base image that accepts source code that it can make runnable, and a custom build that can run // arbitrary container images as a base and accept the build parameters. Builds run on the cluster and on completion are pushed to the container image registry specified in the "output" section. A build can be triggered via a webhook, when the base image changes, or when a user manually requests a new build be // created.


        Each build created by a build configuration is numbered and refers back to its parent configuration. Multiple builds can be triggered at once. Builds that do not have "output" set can be used to test code or run a verification build.


        Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer).

      • getStatus

        public BuildConfigStatus getStatus()
        Build configurations define a build process for new container images. There are three types of builds possible - a container image build using a Dockerfile, a Source-to-Image build that uses a specially prepared base image that accepts source code that it can make runnable, and a custom build that can run // arbitrary container images as a base and accept the build parameters. Builds run on the cluster and on completion are pushed to the container image registry specified in the "output" section. A build can be triggered via a webhook, when the base image changes, or when a user manually requests a new build be // created.


        Each build created by a build configuration is numbered and refers back to its parent configuration. Multiple builds can be triggered at once. Builds that do not have "output" set can be used to test code or run a verification build.


        Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer).

      • setStatus

        public void setStatus​(BuildConfigStatus status)
        Build configurations define a build process for new container images. There are three types of builds possible - a container image build using a Dockerfile, a Source-to-Image build that uses a specially prepared base image that accepts source code that it can make runnable, and a custom build that can run // arbitrary container images as a base and accept the build parameters. Builds run on the cluster and on completion are pushed to the container image registry specified in the "output" section. A build can be triggered via a webhook, when the base image changes, or when a user manually requests a new build be // created.


        Each build created by a build configuration is numbered and refers back to its parent configuration. Multiple builds can be triggered at once. Builds that do not have "output" set can be used to test code or run a verification build.


        Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer).

      • getAdditionalProperties

        public Map<String,​Object> getAdditionalProperties()
      • setAdditionalProperty

        public void setAdditionalProperty​(String name,
                                          Object value)
      • setAdditionalProperties

        public void setAdditionalProperties​(Map<String,​Object> additionalProperties)