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

Emit events for BuildRun objects #824

Closed
wants to merge 1 commit into from

Conversation

adambkaplan
Copy link
Member

@adambkaplan adambkaplan commented Jun 25, 2021

Changes

Enhance the BuildRun controller to emit k8s events when build runs start
and complete. If a BuildRun fails, a Warning event is issued.

This is an initial implementation for #823

/kind feature

Submitter Checklist

  • Includes tests if functionality changed/was added
  • Includes docs if changes are user-facing
  • Set a kind label on this PR
  • Release notes block has been filled in, or marked NONE

Release Notes

The build controller will emit Kubernetes events when a BuildRun starts and completes. If the BuildRun fails, a Warning event will be issued.

@openshift-ci openshift-ci bot added release-note Label for when a PR has specified a release note kind/feature Categorizes issue or PR as related to a new feature. labels Jun 25, 2021
@openshift-ci openshift-ci bot requested review from HeavyWombat and sbose78 June 25, 2021 20:10
@openshift-ci
Copy link
Contributor

openshift-ci bot commented Jun 25, 2021

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To complete the pull request process, please ask for approval from adambkaplan after the PR has been reviewed.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Enhance the BuildRun controller to emit k8s events when build runs start
and complete. If a BuildRun fails, a Warning event is issued. Includes
updates to the BuildRun documentation.
Copy link
Member

@SaschaSchwarze0 SaschaSchwarze0 left a comment

Choose a reason for hiding this comment

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

Generally something that is valuable. But, my first reaction honestly was: hm, I might have missed that ep/shp. There, we could have thought about the events that we want to emit; whether we want to make the feature configurable or not.

}

// recordBuildRunCompleted records the appropriate event if the provided BuildRun has completed.
func (r *ReconcileBuildRun) recordBuildRunCompleted(buildRun *buildv1alpha1.BuildRun) {
Copy link
Member

Choose a reason for hiding this comment

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

My few cents: the function names sound generic and not related to events. The metrics calls could therefore also go in here. What I tend to prefer more is that the event creation code is moved to a separate file.

@@ -126,6 +126,7 @@ func (r *ReconcileBuildRun) Reconcile(request reconcile.Request) (reconcile.Resu
// Set OwnerReference for Build and BuildRun only when build.shipwright.io/build-run-deletion is set "true"
if build.GetAnnotations()[buildv1alpha1.AnnotationBuildRunDeletion] == "true" && !resources.IsOwnedByBuild(build, buildRun.OwnerReferences) {
if err := r.setOwnerReferenceFunc(build, buildRun, r.scheme); err != nil {
// TODO - why are we setting this on the Build object instead of the BuildRun object?
Copy link
Member

Choose a reason for hiding this comment

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

I personally prefer that issues are opened instead of adding TODOs in unrelated pull requests that nobody will work on.

Copy link
Member Author

Choose a reason for hiding this comment

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

Opened #827 - I'll drop this comment

@qu1queee
Copy link
Contributor

@adambkaplan I agree on what Sascha mentioned, we should send this via a SHIP first. I´m doing the same in #787 (comment) .

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Jul 29, 2021

@adambkaplan: PR needs rebase.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@openshift-ci openshift-ci bot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jul 29, 2021
@adambkaplan
Copy link
Member Author

/close

Will reconsider/reopen this after discussing in a SHIP.

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Nov 17, 2021

@adambkaplan: Closed this PR.

In response to this:

/close

Will reconsider/reopen this after discussing in a SHIP.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@openshift-ci openshift-ci bot closed this Nov 17, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature. needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. release-note Label for when a PR has specified a release note
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants