-
Notifications
You must be signed in to change notification settings - Fork 586
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
feat: update github adapter spec #1306
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: Remi Cattiau <[email protected]>
Signed-off-by: Remi Cattiau <[email protected]>
Signed-off-by: Remi Cattiau <[email protected]>
Signed-off-by: Remi Cattiau <[email protected]>
Signed-off-by: Remi Cattiau <[email protected]>
Signed-off-by: Remi Cattiau <[email protected]>
Signed-off-by: Remi Cattiau <[email protected]>
cloudevents/adapters/github.md
Outdated
| `datacontenttype` | `application/json` | | ||
| `dataschema` | Omit | | ||
| `subject` | "package.id" value | | ||
| `time` | "package.(created\|updated)\_at" value | |
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.
it's interesting that the doc says that "created_at" can be null - I wonder how that can be.
I wonder if we should say the value should be taken in this order: updated_at, created_at, current time
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 GH event can be a bit 'weird' i like the updated_at|created_at|now()
but a bit painful to write
| `datacontentencoding` | Omit | | ||
| `datacontenttype` | `application/json` | | ||
| `dataschema` | Omit | | ||
| `subject` | "repository.name" value | |
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.
repository_ruleset.id ?
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.
The id is really not that useful to filter on
| `datacontenttype` | `application/json` | | ||
| `dataschema` | Omit | | ||
| `subject` | "repository.name" value | | ||
| `time` | "repository.updated_at" value | |
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.
or current time if not present?
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.
Should we add a comment on the top that claim for time attribute if null or invalid fallback to current time?
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.
Sure
| `datacontenttype` | `application/json` | | ||
| `dataschema` | Omit | | ||
| `subject` | "alert.id" value | | ||
| `time` | "alert.updated_at" value or "alert.created_at" | |
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.
might want to add something about updated_at should be used unless null
| `datacontenttype` | `application/json` | | ||
| `dataschema` | Omit | | ||
| `subject` | "alert.id" value | | ||
| `time` | "alert.updated_at" value or "alert.created_at" | |
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.
same as above... updated_at if not null
| `datacontentencoding` | Omit | | ||
| `datacontenttype` | `application/json` | | ||
| `dataschema` | Omit | | ||
| `subject` | Omit | |
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.
maybe repository.id ?
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.
Same as first comment, we have the repository url in source, not sure we need the id in subject
| `datacontentencoding` | Omit | | ||
| `datacontenttype` | `application/json` | | ||
| `dataschema` | Omit | | ||
| `subject` | "workflow_job.name" value | |
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 wonder if workflow_job.id is better in the case of a rename?
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.
Most of GH ui only show the name, so my assumption is name would be more useful.
I do not know if the id change or not on rename
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.
what about workflow_job.run_url?
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.
So run_url bring you to a page that does not even contain the info of the job, the url
which is different from run_url
can be derived from the id
but as I dont think you can really predict the id, it seems to me like a bit fastidious to filter on. My initial guess is we want to have valuable information to ease filtering.
For example it is likely i will want to target a specific workflow name in a specific repository so filtering on both source and a startsWith on subject
| `datacontentencoding` | Omit | | ||
| `datacontenttype` | `application/json` | | ||
| `dataschema` | Omit | | ||
| `subject` | "workflow.name" value | |
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.
workflow_run.id?
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 can't figure out of "name" need to be unique or not. I'm assuming 'id' must be.
From co-pilot:
the name field in a GitHub workflow does not need to be unique. The name is used for display purposes and helps you identify the workflow in the GitHub Actions tab
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.
actually, should this be the workflow.url ?
@loopingz any update on this? |
Signed-off-by: Remi Cattiau <[email protected]>
Conditionally approved on the 8/29 call - once the open comments are closed |
This Pull Request is stale because it has been open for 30 days with |
@loopingz did you want to reply to the open comments? |
This Pull Request is stale because it has been open for 30 days with |
ping @loopingz |
Proposed Changes