feat!: merge subject.source into subject.id

[davidB]

Changes

Merge subject.source into subject.id:

• subject.id definition change (becomes an URI-reference, an global)
• remove subject.source and content.{service,repository,pipelineRun,environment}.source

see: #252 for initial proposal / discussion

Submitter Checklist

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

• Has the primer doc been updated if a design decision is involved
• Have the JSON schemas been updated if the specification changed
• Has spec version and event versions been updated according to the versioning policy
• Meets the CDEvents contributor standards

[afrittoli]

Looks good! We'll need to document this change carefully in the release notes

[xibz]

During the SIG April 21st, 2026, we (@dsanyika and I) should probably keep subject.source as separate, but make it a required field instead. That may solve your issue @davidB, thoughts?

[davidB]

That solves part of the issue.
The advantage of the merging:

• Only one field to look for when linking/referencing (easier also when creating Database, graph, rules, ...)
• No question for the case where id is already an absolute URI, like for artifacts
• No additional questions/rules about how to split between id and source for a global id/reference.

Some example (you can try to split between the source and id):

• a repository: ${.body.repository.url} (on GitHub event), else we have to reconstruct it with like https://${host}(:${port}?/${owner}/${repo} (iirc on GitLab ${owner} can be a path of several levels). (remimder, github, gitlab, ... can run on-premises)
• a pipelinerun id for github: ${.body.workflow_run.url}/attempts/${.body.workflow_run.run_attempt} (https://api.github.com/repos/cdviz-dev/cdviz-collector/actions/runs/24767867847/attempts/1)
• a pipelinerun id for gitlab: ${project_web_url}/-/pipelines/${pipeline.id} (no concept of rerun/attempt at pipeline level in gitlab iirc, but present for taskrun).
• a github issue: https://github.com/cdevents/spec/issues/305
• a jira issue: https://example.atlassian.net/browse/PROJ-1
• a change id (for github): ${.body.pull_request.url} (eg https://github.com/cdevents/spec/pull/302)
• a service id:
  • ${namespace}/${resource_name}/${container_name} (when packageId is a container image running on a kubernetes cluster)
  • ${namespace}/${resource_name} (when the packageId is a resource like helm chart, argo application, ...)

IMHO, it's not the purpose of CDEvents to define the rules (how to split or extract information) for each provider; we already have to work on removing questions/ambiguity and share real example.
I'll watch the meeting records when I'll be back.