-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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.
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
Update build status to indicate build failure reason #10817
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -10,6 +10,8 @@ import ( | |
"github.com/docker/distribution/reference" | ||
"github.com/fsouza/go-dockerclient" | ||
|
||
kclient "k8s.io/kubernetes/pkg/client/unversioned" | ||
|
||
"github.com/openshift/origin/pkg/build/api" | ||
"github.com/openshift/origin/pkg/client" | ||
"github.com/openshift/origin/pkg/generate/git" | ||
|
@@ -20,7 +22,14 @@ import ( | |
// client facing libraries should not be using glog | ||
var glog = utilglog.ToFile(os.Stderr, 2) | ||
|
||
const OriginalSourceURLAnnotationKey = "openshift.io/original-source-url" | ||
const ( | ||
OriginalSourceURLAnnotationKey = "openshift.io/original-source-url" | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @bparees please open a follow up to move this to pkg/build/api and add Godoc. It doesn't follow our API conventions either. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @csrwng it looks like you added this.. is anything using this other than the git server? are we going to break anything meaningful if we change the annotation name? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @bparees so this is used for the case where we have to use a proxy because the password is too long to be used directly with git. True, it was mainly for the use case of the git server because we use service account tokens... but it could be used in other cases where you have a long password/token. It was only a temporary solution until git supported long passwords in centos/rhel. With 7.3 it's no longer necessary. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. opened issue to track removing this stuff: #11969 |
||
|
||
// containerNamePrefix prefixes the name of containers launched by a build. | ||
// We cannot reuse the prefix "k8s" because we don't want the containers to | ||
// be managed by a kubelet. | ||
containerNamePrefix = "openshift" | ||
) | ||
|
||
// KeyValue can be used to build ordered lists of key-value pairs. | ||
type KeyValue struct { | ||
|
@@ -66,35 +75,6 @@ func buildInfo(build *api.Build) []KeyValue { | |
return kv | ||
} | ||
|
||
func updateBuildRevision(c client.BuildInterface, build *api.Build, sourceInfo *git.SourceInfo) { | ||
if build.Spec.Revision != nil { | ||
return | ||
} | ||
build.Spec.Revision = &api.SourceRevision{ | ||
Git: &api.GitSourceRevision{ | ||
Commit: sourceInfo.CommitID, | ||
Message: sourceInfo.Message, | ||
Author: api.SourceControlUser{ | ||
Name: sourceInfo.AuthorName, | ||
Email: sourceInfo.AuthorEmail, | ||
}, | ||
Committer: api.SourceControlUser{ | ||
Name: sourceInfo.CommitterName, | ||
Email: sourceInfo.CommitterEmail, | ||
}, | ||
}, | ||
} | ||
|
||
// Reset ResourceVersion to avoid a conflict with other updates to the build | ||
build.ResourceVersion = "" | ||
|
||
glog.V(4).Infof("Setting build revision to %#v", build.Spec.Revision.Git) | ||
_, err := c.UpdateDetails(build) | ||
if err != nil { | ||
glog.V(0).Infof("error: An error occurred saving build revision: %v", err) | ||
} | ||
} | ||
|
||
// randomBuildTag generates a random tag used for building images in such a way | ||
// that the built image can be referred to unambiguously even in the face of | ||
// concurrent builds with the same name in the same namespace. | ||
|
@@ -108,11 +88,6 @@ func randomBuildTag(namespace, name string) string { | |
return fmt.Sprintf("%s:%s", repo, randomTag) | ||
} | ||
|
||
// containerNamePrefix prefixes the name of containers launched by a build. We | ||
// cannot reuse the prefix "k8s" because we don't want the containers to be | ||
// managed by a kubelet. | ||
const containerNamePrefix = "openshift" | ||
|
||
// containerName creates names for Docker containers launched by a build. It is | ||
// meant to resemble Kubernetes' pkg/kubelet/dockertools.BuildDockerName. | ||
func containerName(strategyName, buildName, namespace, containerPurpose string) string { | ||
|
@@ -180,3 +155,47 @@ func execPostCommitHook(client DockerClient, postCommitSpec api.BuildPostCommitS | |
Stderr: true, | ||
}) | ||
} | ||
|
||
func updateBuildRevision(build *api.Build, sourceInfo *git.SourceInfo) *api.SourceRevision { | ||
if build.Spec.Revision != nil { | ||
return build.Spec.Revision | ||
} | ||
return &api.SourceRevision{ | ||
Git: &api.GitSourceRevision{ | ||
Commit: sourceInfo.CommitID, | ||
Message: sourceInfo.Message, | ||
Author: api.SourceControlUser{ | ||
Name: sourceInfo.AuthorName, | ||
Email: sourceInfo.AuthorEmail, | ||
}, | ||
Committer: api.SourceControlUser{ | ||
Name: sourceInfo.CommitterName, | ||
Email: sourceInfo.CommitterEmail, | ||
}, | ||
}, | ||
} | ||
} | ||
|
||
func retryBuildStatusUpdate(build *api.Build, client client.BuildInterface, sourceRev *api.SourceRevision) error { | ||
return kclient.RetryOnConflict(kclient.DefaultBackoff, func() error { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why isn't this a PATCH? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @smarterclayton can you give me an example where we do it with patch so that i can change it accordingly? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sounds like a broken telephone. We added Patch in the idling controller for DCs and RCs. I think Patch in controllers makes sense in cases where the resource to be updated is not the main resource owned by the controller and you always want the update to succeed (eg. you mark a deployment as {inert,cancelled,complete,...} or you adopt a replica set). That being said it doesn't seem that you use There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. yes technically it's the builder image, but realistically we can consider actions the builder image takes to be direct extensions of actions the controller takes. And it is the primary object (the build object, owned by the controller) that's being updated. So it seems like using update would follow the existing patterns, such as they are. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. so do i leave it as it is? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @smarterclayton can you weigh back in? is using patch from controllers(or in this case, a process that's subservient to a controller) a pattern we're trying to move to? or should this be left as is since it's aligned w/ what we're doing elsewhere today? @Kargakis can you point us to the code where you do patch in the idling controller? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @smarterclayton ^^ ping! |
||
// before updating, make sure we are using the latest version of the build | ||
latestBuild, err := client.Get(build.Name) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @csrwng i'm trying to avoid an update conflict to the build object, and i need to get the latest version of the object, the problem is i don't have credentials to do so from the builders, just need a Get()
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @liggitt @deads2k the above code fails with
i tried adding a serviceaccount:builder like this: i also tried adding There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. adding the get rule to the system:image-builder role would work:
you need to run There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @liggitt it worked, thank you very much! |
||
if err != nil { | ||
// usually this means we failed to get resources due to the missing | ||
// privilleges | ||
return err | ||
} | ||
if sourceRev != nil { | ||
latestBuild.Spec.Revision = sourceRev | ||
latestBuild.ResourceVersion = "" | ||
} | ||
|
||
latestBuild.Status.Reason = build.Status.Reason | ||
latestBuild.Status.Message = build.Status.Message | ||
|
||
if _, err := client.UpdateDetails(latestBuild); err != nil { | ||
return err | ||
} | ||
return nil | ||
}) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what about failures during committing the container and pushing the image?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bparees do we have a way to know when the commit failed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we're explicitly invoking commit on the container, so i'd assume so... (for s2i builds. not for docker builds, of course)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nm, I was thinking about the separation between s2i code and the origin builder code, but the commit happens within the same process as the origin builder container.