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

Add user field to artifact events and download and delete events #172

Merged
merged 2 commits into from
Jan 16, 2024

Conversation

afrittoli
Copy link
Contributor

@afrittoli afrittoli commented Nov 26, 2023

Changes

Cleaned up some wrong references, left over when moving test events, added both testing and artifact events to spec.md too. Add the user field to the artifact push event and it introduces the artifact pulled and deleted events, both with a user field too.

Partially-fixes: #143

Submitter Checklist

As the author of this PR, please check off the items in this checklist:

@afrittoli afrittoli changed the title Move artifact events to their own file Move artifact events to their own file and add more pull and delete events Nov 27, 2023
@afrittoli afrittoli changed the title Move artifact events to their own file and add more pull and delete events Move artifact events, add user field and pull and delete events Nov 27, 2023
@afrittoli afrittoli force-pushed the artifact_events branch 2 times, most recently from a08792a to 0d575b0 Compare November 27, 2023 07:42
@e-backmark-ericsson
Copy link
Contributor

I don't really see why there would need to be an artifact.pulled CDEvent defined. What use case would it serve in a CI/CD context?

@mekhanique
Copy link

mekhanique commented Dec 4, 2023

My $0.02 for what it's worth @e-backmark-ericsson . . .

Artifact pulled (or quarantined as I prefer because an "existing" but "un-useable" artifact helps to ensure that said "bad artifact" is not accidentally re-proxied/re-deployed) should initiate downstream actions that impact deployments (future or existing) for software and services which identifies said artifact within its SBOMs. An upstream deployment/release system could monitor for this event and "mark" said software/service un-useable. Reasons for this could be a high severity security finding such as RCE, a legal (licensing or patent) finding, the artifact becoming un-supported (internally or externally), or any other policy that a company might need to implement within this space, such as not using old major versions of a dependency.

While not "best practices" from a pure CD point of view, automated roll-backs are performed based on some of these events in live systems today. Events in this space enable automation to be created that helps streamline processes that use this model today.

Additionally, a quarantine event could trigger automated dependency update pipelines (such as those that might be done via Dependabot, Update-CLI or as otherwise suggested in #39). That would again streamline the process for companies that need to roll-forward as fast as they can.

@afrittoli
Copy link
Contributor Author

I don't really see why there would need to be an artifact.pulled CDEvent defined. What use case would it serve in a CI/CD context?

Heh, I might want to be notified if a certain artifact is downloaded.

@mekhanique
Copy link

mekhanique commented Dec 5, 2023 via email

@afrittoli afrittoli requested a review from a team as a code owner January 12, 2024 14:58
@afrittoli
Copy link
Contributor Author

My $0.02 for what it's worth @e-backmark-ericsson . . .

Artifact pulled (or quarantined as I prefer because an "existing" but "un-useable" artifact helps to ensure that said "bad artifact" is not accidentally re-proxied/re-deployed) should initiate downstream actions that impact deployments (future or existing) for software and services which identifies said artifact within its SBOMs. An upstream deployment/release system could monitor for this event and "mark" said software/service un-useable. Reasons for this could be a high severity security finding such as RCE, a legal (licensing or patent) finding, the artifact becoming un-supported (internally or externally), or any other policy that a company might need to implement within this space, such as not using old major versions of a dependency.

While not "best practices" from a pure CD point of view, automated roll-backs are performed based on some of these events in live systems today. Events in this space enable automation to be created that helps streamline processes that use this model today.

Additionally, a quarantine event could trigger automated dependency update pipelines (such as those that might be done via Dependabot, Update-CLI or as otherwise suggested in #39). That would again streamline the process for companies that need to roll-forward as fast as they can.

Thanks. I renamed "pulled" do "downloaded". I will follow up on the idea of "quarantined" in a separate PR

@afrittoli
Copy link
Contributor Author

@e-backmark-ericsson @xibz ready for review

@afrittoli afrittoli changed the title Move artifact events, add user field and pull and delete events Add user field to artifact events and pull and delete events Jan 12, 2024
Cleaned up some wrong references, left over when moving test events,
added testing events to spec.md too.

Partially-fixes: cdevents#143

Signed-off-by: Andrea Frittoli <andrea.frittoli@gmail.com>
@afrittoli afrittoli changed the title Add user field to artifact events and pull and delete events Add user field to artifact events and download and delete events Jan 15, 2024
Signed-off-by: Andrea Frittoli <andrea.frittoli@gmail.com>
@afrittoli afrittoli merged commit ba07b76 into cdevents:main Jan 16, 2024
@afrittoli afrittoli added this to the v0.4 milestone Apr 2, 2024
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.

Events for artifact repositories
3 participants