Skip to content
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

Report multiple build causes for image change triggers #14777

Conversation

smarterclayton
Copy link
Contributor

Improve tests

[test]

@bparees this is not a fix to #14725, but increases coverage and is more accurate.

Message: buildapi.BuildTriggerCauseImageMsg,
ImageChangeBuild: &buildapi.ImageChangeCause{
ImageID: id,
ImageID: latest,
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This might actually be a bug - I don't know that we depend on this, but it was not set before ever.

Copy link
Contributor

Choose a reason for hiding this comment

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

yeah I don't think we depend on it, just informational to the user (we use the TriggeryByImage content to actually set the base image used for the build) but good catch regardless.

@smarterclayton smarterclayton force-pushed the improve_tests_for_buildconfigtrigger branch from 28a0f8a to 4133754 Compare June 20, 2017 17:39
Copy link
Contributor

@bparees bparees left a comment

Choose a reason for hiding this comment

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

i'm not convinced this new behavior makes sense. ultimately what this does is submit a buildrequest for a build with a single "triggeredbyimage" value. And the build that gets run will use that "triggeredbyimage" value as the base image, and update that specific trigger within the BC to indicate what image it last triggered on.

If 3 images change simultaneously, and the build has triggers for all 3, then we will go through 3 distinct buildrequests, each one containing one of the images as the "triggeredbyimage" value.

So it doesn't seem correct for any of those to also report all 3 images as the "buildtriggercause", because we're really only reacting to(running a build that explicitly consumes) a specific one of them.

it is true that if the BC consumes multiple images, we'll also be resolving the other imagestream references, but that's implicit, not explicit.

Message: buildapi.BuildTriggerCauseImageMsg,
ImageChangeBuild: &buildapi.ImageChangeCause{
ImageID: id,
ImageID: latest,
Copy link
Contributor

Choose a reason for hiding this comment

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

yeah I don't think we depend on it, just informational to the user (we use the TriggeryByImage content to actually set the base image used for the build) but good catch regardless.


// prevent duplicate build trigger causes
if fired == nil {
fired = make(map[kapi.ObjectReference]string)
Copy link
Contributor

Choose a reason for hiding this comment

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

why not initialize this where you declared the variable? going for efficiency?

@smarterclayton
Copy link
Contributor Author

smarterclayton commented Jun 20, 2017

If 3 images change simultaneously, and the build has triggers for all 3, then we will go through 3 distinct buildrequests, each one containing one of the images as the "triggeredbyimage" value.

Um... why would we do that?

@smarterclayton
Copy link
Contributor Author

We currently resolve all triggers at build instantiate time - so we would not trigger 3.

@bparees
Copy link
Contributor

bparees commented Jun 20, 2017

We currently resolve all triggers at build instantiate time - so we would not trigger 3.

ok yeah, i forgot we do that, however it's still the case that what is happening is we are running a build that explicitly picks up a particular image, and then implicitly picks up the rest.

Meaning that the build is guaranteed to use the one image listed in the triggeredbyimage section (and what was supposed to be listed in the triggeredby section), it is not guaranteed to use all N images that you are now listing in the triggeredby section. Essentially you're just using the triggeredby section as "other stuff that was also different when we ran this build. the build may pick these up, if they are not replaced with something even newer before this build runs".

If you prefer that, ok, it's certainly potentially useful information, but the implication/meaning is definitely a bit fuzzy.

@bparees
Copy link
Contributor

bparees commented Jun 20, 2017

(well, "before this build runs" is an overstatement since the resolution happens during instantiate, not when the build runs. so there's almost no chance the build runs with anything different than what you're going to report, but it is non-zero)

@smarterclayton
Copy link
Contributor Author

smarterclayton commented Jun 20, 2017 via email

@bparees
Copy link
Contributor

bparees commented Jun 20, 2017

I think from an end user perspective, id want to see all of the causes listed.

then i guess my only open question is the way you're initializing the map, but i assume you're doing that to save initializing it when we don't enter the condition.

@smarterclayton
Copy link
Contributor Author

smarterclayton commented Jun 20, 2017 via email

@smarterclayton
Copy link
Contributor Author

[test]

@smarterclayton
Copy link
Contributor Author

Any other comments?

@bparees
Copy link
Contributor

bparees commented Jun 23, 2017

lgtm

@smarterclayton
Copy link
Contributor Author

[merge]

@smarterclayton
Copy link
Contributor Author

[severity:bug]

@deads2k
Copy link
Contributor

deads2k commented Jun 26, 2017

re[test]

@smarterclayton
Copy link
Contributor Author

smarterclayton commented Jun 27, 2017 via email

@openshift-bot
Copy link
Contributor

openshift-bot commented Jun 27, 2017

continuous-integration/openshift-jenkins/merge Waiting: You are in the build queue at position: 2

@smarterclayton smarterclayton force-pushed the improve_tests_for_buildconfigtrigger branch from 4133754 to 19872e4 Compare June 27, 2017 03:23
@openshift-bot
Copy link
Contributor

Evaluated for origin merge up to 19872e4

@smarterclayton
Copy link
Contributor Author

[test]

2 similar comments
@smarterclayton
Copy link
Contributor Author

[test]

@smarterclayton
Copy link
Contributor Author

[test]

@openshift-bot
Copy link
Contributor

Evaluated for origin test up to 19872e4

@openshift-bot
Copy link
Contributor

continuous-integration/openshift-jenkins/test SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pull_request_origin/2768/) (Base Commit: 478cfe2) (PR Branch Commit: 19872e4)

@smarterclayton smarterclayton merged commit c4ad769 into openshift:master Jun 28, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants