Skip to content

Added incremental buildConfig #465

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
adellape merged 1 commit into from
Jun 10, 2015
Merged

Added incremental buildConfig #465

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
205 changes: 119 additions & 86 deletions dev_guide/builds.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -84,6 +84,33 @@ The `*ImageChange*` trigger creates a new build each time the Docker image speci
<4> The `*strategy*` section describes the build strategy used to execute the build. You can specify `*Source*`, `*Docker*` and `*Custom*` strategies here. This specification uses the `*ruby-20-centos7*` Docker image that Source-To-Image will use for the application build.
<5> After the Docker image is successfully built, it will be pushed into the repository described in the `*output*` section.

== Defining an incremental buildConfig
Copy link
Contributor

@bparees bparees Jun 9, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BuildConfig ?

Copy link
Author

@soltysh soltysh Jun 9, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking of my paragraph as being the continuation of the previous one, where buildConfig is used.

Source-To-Image (S2I) builds provide an option to perform incremental build, which means they will
reuse artifacts from previously built image. To create an incremental build one
needs to create a BuildConfig as previously explained, but with a slight modification
in strategy definition as presented below:

[incremental.json]
----
{
"strategy": {
"type": "Source",
"sourceStrategy": {
"from": {
"kind": "ImageStreamTag",
"name": "incremental-image:latest" <1>
},
"incremental": true <2>
}
}
}
----

<1> You need to specify here an image that supports incremental builds. Note: the S2I images provided by OpenShift do not implement artifact reuse, so setting incremental to true will have no effect on BuildConfigs using those builder images.
Copy link
Contributor

@adellape adellape Jun 9, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since it's an ImageStreamTag, should it more specifically say here that name should specify an image and tag (instead of just image)? I notice the later example is in the form "ruby-20-centos7:latest".

Copy link
Contributor

@bparees bparees Jun 9, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah technically imagestreamtags are required to be of the form name:tag, but an "image" is sort of equivalent to an imagestreamtag. also they could use a DockerImage instead of an ImageStreamTag as the reference type, so i think just generically saying "image" here is probably fine.

Copy link
Contributor

@adellape adellape Jun 9, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, thanks.

Copy link
Author

@soltysh soltysh Jun 10, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still to be consistent and do not mistake users, I'll update adding :latest there.

<2> This flag controls whether an incremental build is attempted. If the builder image does not support incremental builds, the build will still succeed but you will get a log message that the incremental build was not successful because of a missing `save-artifacts` script.

NOTE: For information on how to create a builder image which supports incremental build see link:../creating_images/sti.html[creating images guide].

== Starting a Build
You can manually invoke a build using the following command:

Expand Down Expand Up @@ -127,17 +154,17 @@ environment variable as part of the `*sourceStrategy*` in BuildConfig:
====

----
{
"sourceStrategy": {
...
"env": [
{
"Name": "BUILD_LOGLEVEL",
"Value": "2" <1>
}
]
}
}
{
"sourceStrategy": {
...
"env": [
{
"Name": "BUILD_LOGLEVEL",
"Value": "2" <1>
}
]
}
}
----

<1> Adjust this value to the desired log level.
Expand All @@ -164,15 +191,15 @@ is later built. The source code location definition is part of the
====

----
{
"source" : {
"type" : "Git", <1>
"git" : { <2>
"uri": "git://github.com/openshift/ruby-hello-world.git"
},
"contextDir": "app/dir", <3>
},
}
{
"source" : {
"type" : "Git", <1>
"git" : { <2>
"uri": "git://github.com/openshift/ruby-hello-world.git"
},
"contextDir": "app/dir", <3>
},
}
----

<1> The `*type*` field describes what SCM is used to fetch your source code.
Expand All @@ -189,8 +216,8 @@ default location (the root folder) using this field.
[[configuring-the-source-environment]]
== Source Environment

There are two ways to make environment variables available to the link:../architecture/core_objects/builds.html#source-build[Source]
build process and resulting image, Environment files and BuildConfig environment values.
There are two ways to make environment variables available to the link:../architecture/core_objects/builds.html#source-build[Source]
build process and resulting image, Environment files and BuildConfig environment values.

=== Environment files
Source enables you to set environment values
Expand All @@ -214,7 +241,7 @@ the running application itself. For example, you can add
application to be started in `development` mode instead of `production`.

=== BuildConfig Environment
You can add environment variables to the SourceStrategy definition of the BuildConfig.
You can add environment variables to the SourceStrategy definition of the BuildConfig.
Environment variables defined here will be visible during the *_assemble_* script
execution and will be defined in the output image, making them also available to
the *_run_* script and application code.
Expand Down Expand Up @@ -244,12 +271,12 @@ JSON within the `*BuildConfig*`:
====

----
{
"type": "github",
"github": {
"secret": "secret101"
}
}
{
"type": "github",
"github": {
"secret": "secret101"
}
}
----
====

Expand All @@ -270,12 +297,12 @@ following is an example trigger definition JSON within the `*BuildConfig*`:
====

----
{
"type": "generic",
"generic": {
"secret": "secret101"
}
}
{
"type": "generic",
"generic": {
"secret": "secret101"
}
}
----
====

Expand All @@ -292,21 +319,21 @@ The endpoint can accept an optional payload with the following format:

----
{
type: 'git',
git: {
uri: '<url to git repository>',
ref: '<optional git reference>',
commit: '<commit hash identifying a specific git commit>',
author: {
name: '<author name>',
email: '<author e-mail>',
},
committer: {
name: '<committer name>',
email: '<committer e-mail>',
},
message: '<commit message>'
}
type: 'git',
git: {
uri: '<url to git repository>',
ref: '<optional git reference>',
commit: '<commit hash identifying a specific git commit>',
author: {
name: '<author name>',
email: '<author e-mail>',
},
committer: {
name: '<committer name>',
email: '<committer e-mail>',
},
message: '<commit message>'
}
}
----
====
Expand Down Expand Up @@ -339,13 +366,13 @@ trigger on:
====

----
{
"metadata":{
"name": "ruby-20-centos7",
},
"kind": "ImageStream",
"apiVersion": "v1beta1",
}
{
"metadata":{
"name": "ruby-20-centos7",
},
"kind": "ImageStream",
"apiVersion": "v1beta1",
}
----
====
+
Expand All @@ -360,15 +387,17 @@ example:
====

----
"strategy": {
"type": "Source",
"sourceStrategy": {
"from": {
"kind": "ImageStreamTag",
"name": "ruby-20-centos7:latest"
},
}
{
"strategy": {
"type": "Source",
"sourceStrategy": {
"from": {
"kind": "ImageStreamTag",
"name": "ruby-20-centos7:latest"
},
}
}
}
----
====
+
Expand All @@ -380,10 +409,10 @@ ImageStream named `ruby-20-centos7` located within this namespace.
====

----
{
"type": "imageChange",
"imageChange": {}
}
{
"type": "imageChange",
"imageChange": {}
}
----
====
+
Expand All @@ -396,25 +425,27 @@ for the build. For example, the resulting build will be:
====

----
"strategy": {
"type": "Source",
"sourceStrategy": {
"from": {
"kind": "DockerImage",
"name": "172.30.17.3:5001/mynamespace/ruby-20-centos7:immutableid"
}
{
"strategy": {
"type": "Source",
"sourceStrategy": {
"from": {
"kind": "DockerImage",
"name": "172.30.17.3:5001/mynamespace/ruby-20-centos7:immutableid"
}
}
}
}
----
====

This ensures that the triggered build uses the new image that was just pushed to
the repository, and the build can be re-run anytime with exactly the same
inputs.

In addition to setting the image field for all `*Strategy*` types, for custom builds,
the `OPENSHIFT_CUSTOM_BUILD_BASE_IMAGE` environment variable is checked. If it does
not exist, then it is created with the immutable image reference. If it does exist
In addition to setting the image field for all `*Strategy*` types, for custom builds,
the `OPENSHIFT_CUSTOM_BUILD_BASE_IMAGE` environment variable is checked. If it does
not exist, then it is created with the immutable image reference. If it does exist
then it is updated with the immutable image reference.

If a build is triggered due to a webhook trigger or manual request,
Expand Down Expand Up @@ -475,13 +506,15 @@ that you created, which in the above example is `*dockerhub*`:

====
----
"parameters": {
"output": {
"to": {
"name": "private-image"
},
"pushSecret":{
"name":"dockerhub"
{
"parameters": {
"output": {
"to": {
"name": "private-image"
},
"pushSecret":{
"name":"dockerhub"
}
}
}
}
Expand Down