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.

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

Jump to bottom

Konflux should emit cloud events. #206

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Konflux should emit cloud events. #206

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
34 changes: 34 additions & 0 deletions ADR/0039-send-cloud-events.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,34 @@
# 40. Konflux should send cloud events all system events.

Date: 2024-09-24

## Status

Proposed

## Context

Konflux had made the architectural decision to not use cloud events. However, that does not mean that
Konflux should not emit cloud events.

Emitting cloud events would allow Konflux users to easily track what is happening in the system. In addition,
they can use these cloud events to create their own product-specific infrastructure to support their build
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we use a different term other than "product-specific" throughout this document? AFAIK, Konflux is not aware of what a product is. Maybe use "application-specific"?

Copy link
Contributor

Choose a reason for hiding this comment

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

or even "team-specific" or "org-specific"

and release process.

To support this, all Konflux components should be required to emit cloud events for signicant events. These
Copy link
Contributor

Choose a reason for hiding this comment

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

Let's consider if "should be required to emit" is too strong of a statement. I believe "should emit" better describes the intent.

Copy link
Contributor

Choose a reason for hiding this comment

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

I agree on the "softening"

should be documented fully and made available for users.

Cloud event generation could be optional and that option could default to off. But users should be able to
Copy link
Contributor

Choose a reason for hiding this comment

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

This probably needs clarification on what "users" are. I'm assuming this is a Konflux deployment admin, and not a user that uses Konflux to build content.

Copy link
Member

Choose a reason for hiding this comment

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

From async conversation - I think Greg means for this to be end-users. I.e., the developers that use Konflux to build, test and release their software. He doesn't mean platform engineers (the people running a konflux instance) or other konflux controllers.

turn it on so that Konflux will generate cloud events that they can then act on.

Note again that this ADR does not propose that Konflux generate cloud events for consumption by Konflux
itself. Rather it proposes Konflux generate cloud events to support addtional product-specific build and
release functionality outside of Konflux.

## Decision

All Konflux components shall generate cloud events for significant events.

## Consequences

Product teams can more easily build product-specific build and release infrastructure in Konflux.
Copy link
Member

Choose a reason for hiding this comment

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

Can you add more to this section to make it more clear how, when, and why cloudevents would be used as opposed to extending build, test, or release pipelines?

Copy link
Member

Choose a reason for hiding this comment

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

If this is a path we want to pursue, that likely entails UI support. If we recommend users extend our platform by way of cloudevents, then their sinks and triggers should all get some representation in the UI to visualize what they've assembled and its runtime status.

If that makes sense, then that deserves some elaboration in the Consequences section here.