-
Notifications
You must be signed in to change notification settings - Fork 43
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
Wire new Release + SDLC Core Entities #3839
Conversation
-- See the License for the specific language governing permissions and | ||
-- limitations under the License. | ||
|
||
ALTER TYPE entities ADD VALUE 'release'; |
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.
could we add a transaction here so either the migration proceeds or fails as a whole?
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.
I remember what happened when we hit this bug so this is good feedback 😃
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.
Yeah good call, added it 👍
@puerco Where do you see us using |
// ReleaseEntity is an entity abstracting a release | ||
ReleaseEntity EntityType = "release" | ||
// PipelineRunEntity is an entity abstracting a pipeline run (eg a workflow) | ||
PipelineRunEntity EntityType = "pipeline_run" | ||
// TaskRunEntity is an entity abstracting a task run (eg a step) | ||
TaskRunEntity EntityType = "task_run" | ||
// BuildEntity is an entity that represents a software build | ||
BuildEntity EntityType = "build" |
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.
@eleftherias - I think this is where @puerco put more info about which corresponds to what in GitHub terms. In that sense, I guess task_run
might be a job instead of a step. And also if pipeline_run
is the workflow, then what is the build
? But I guess we don't have to define these now, right? We can do that once we start figuring out the specific provider implementation
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.
@eleftherias @rdimitrov yes, with these new events we should be able to write rules against the results of a Workflow (a PipelineRun in cd events terms), a Step (a TaskRun in cd events) and also to published releases.
The build itself in GitHub terms will look like a subclass of a Step run. It will share a lot of attributes but also has some particulars that differ from a regular Step run that we will need to check (dependencies, the builder, etc).
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.
Do you know what kind of rules we want to write against the results of a PipelineRun
and TaskRun
? I'm not yet seeing how they tie into the new rules we wanted to write and I want to make sure we're not adding entities that will sit around unused.
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.
Perhaps it's difficult to add a specific answer, but my understanding is this should allows us to have more control over the software release lifecycle, i.e. at the end of this (workflow, job, step) we should have that, if not - block executing what's coming next.
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.
I guess another example would be to gather some metadata after each step of the delivery process and store it into an attestation.
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.
Added a few comments, but apart from the need to rebase I think we can merge it 👍
This commit adds 'release' plus some of the core subjects of the cd events spec as entities to the minder protos: ENTITY_RELEASE ENTITY_PIPELINE_RUN ENTITY_TASK_RUN ENTITY_BUILD Signed-off-by: Adolfo García Veytia (Puerco) <puerco@stacklok.com>
This commit adds stub messages for the SDLC entities: Release PipelineRun TaskRun Build Signed-off-by: Adolfo García Veytia (Puerco) <puerco@stacklok.com>
This commit adds up and down (although down is empty) migrations to add release and the core cd events subjects to the sql entities type. Signed-off-by: Adolfo García Veytia (Puerco) <puerco@stacklok.com>
(Run make gen) Signed-off-by: Adolfo García Veytia (Puerco) <puerco@stacklok.com>
This adds release and the core SLDX entity types to the profile functions Signed-off-by: Adolfo García Veytia (Puerco) <puerco@stacklok.com>
This commit adds the release and SLDC entities to the control plane functions Signed-off-by: Adolfo García Veytia (Puerco) <puerco@stacklok.com>
This commit wires the SDLC entities to the engine functions and creates the With* functional options for the new types. Signed-off-by: Adolfo García Veytia (Puerco) <puerco@stacklok.com>
This commit adds NOOP cases to functions where the SDLC entities need to be implemented in the database or, where hardcoded entity types in functions prevent us from wiring up the values. Signed-off-by: Adolfo García Veytia (Puerco) <puerco@stacklok.com>
Signed-off-by: Adolfo García Veytia (Puerco) <puerco@stacklok.com>
OK, I rebased and fixed the wreck from last night's changes. PTAL! |
Summary
This PR adds new entities to enable us to create new minder integrations into the software development lifecycle. The new entities are named based on the CD Events specification conventions when possible and include:
This PR adds the new entity types to the protos in ebc10f5, creates stub messages in bba557f and wires them to the Minder machinery.
Storage of the new entities into the database is not yet implemented as the data structures are not yet defined but this PR includes the migrations to add the new entities to the sql type enum in 268e217
Line count is high but most of the changes lines come from code regeneration in f68e844
Note: This PR is intended to be innocuous: No provider is yet reacting or implementing logic to handle any of these new types, it should have no effect. Where possible, the entity types are fully wired in, when not I've added NOOP cases that will be replaced when the data structures are defined
/cc @eleftherias @rdimitrov
Change Type
Mark the type of change your PR introduces:
Testing
Outline how the changes were tested, including steps to reproduce and any relevant configurations.
Attach screenshots if helpful.
Review Checklist: