Consider taking advantage of this list of task/step types when qualifying event types

[amfred]

See: https://github.com/cdfoundation/sig-interoperability/pull/81

In the working Event Vocabulary document under ["Events Categories"(https://hackmd.io/lBlDCrL7TvmtNOjxdopJ5g) we have a list of event types. Consider using the same terminology as that proposed for the Interoperability SIG's CI/CD Vocabulary.

For example, you have "Build", "Test", and "Release" events, while the Interoperability SIG vocabulary document has "Build", "Test", "Tag", "Publish" and "Deploy". ("Release" can mean "Tag", "Publish" and/or "Deploy" depending on who's using the term; are they talking about tagging the current commit in Github as version 3.7, publishing a new version of a package to NPM, or deploying a new running version of software to your production environment?)

[m-linner-ericsson]

That document is rather old. We now have the spec on https://cdevents.dev/docs/.

[amfred]

The PRs with the terminology have been merged now, see: https://github.com/cdfoundation/sig-interoperability/blob/master/docs/vocabulary.md#mapping-of-terms, https://github.com/cdfoundation/sig-interoperability/blob/master/docs/vocabulary.md#pipeline-stages and https://github.com/cdfoundation/sig-interoperability/blob/master/docs/vocabulary.md#pipeline-step-types

[e-backmark-ericsson]

@amfred, as you were looking at an old document when creating this issue, do you think it is still valid? I believe the terms are now at least more or less up-to-date and aligned with the steps defined in sig-interop.

[e-backmark-ericsson]

It struck me that we should probably rename our TaskRun events to become Step events instead, if we should follow that vocabulary. And we should probably add corresponding Stage events as well.

[e-backmark-ericsson]

I believe we should be aligned with this terminology already for our release 0.1, to not introduce too many non-backwards compliant changes later

[afrittoli]

It struck me that we should probably rename our TaskRun events to become Step events instead, if we should follow that vocabulary. And we should probably add corresponding Stage events as well.

I agree we should converge the terminology. But I'm a bit concerned about this comment:

The effort of proposing a common vocabulary across CI/CD Tools and Technologies is not yet performed, but we'll use the most common term from the table above as the working term.

I think this means that names might change, and thus our spec with them, but I guess that's acceptable as long as we're in a 0.x release.

About steps specifically, if I understand it correctly, the model of the interoperability vocabulary is a pipeline is made of stages and each stage is made of steps. In CDEvents a pipeline is made of taskruns, so perhaps a taskrun would be a stage? We would not have anything to model steps then though.

One semantic difference that I believe exists between CDEvents and the vocabulary is that in CDEvents the "core" events are specific to pipeline orchestrators, where a pipeline is defined somewhere and the orchestrator executes it. In my understanding the concept of pipeline in the vocabulary is more abstract - it's the series of stages that make the entire CD workflow, but it's not necessarily a single orchestrated pipeline (e.g. a Tekton pipeline, a Jenkins pipeline etc). The different stages could be implemented as a single orchestrated pipeline, or each stage could be an independent pipeline, linked to the other via some automation or manual approval.

[amfred]

A Step in the vocabulary I worked on would map to a Tekton TaskRun. Example:

  tasks:
    - name: setup-init
      params:
        - name: image-url
          value: "$(params.output-image)"
      taskRef:
        name: init
    - name: source-clone-repository
      runAfter:
        - setup-init
      params:
        - name: url
          value: $(params.git-url)
        - name: revision
          value: "$(params.revision)"
      taskRef:
        name: git-clone
      workspaces:
        - name: output
          workspace: workspace
        - name: basic-auth
          workspace: git-auth
    - name: build-configure-build
      runAfter:
        - source-clone-repository
      taskRef:
        name: configure-build
      workspaces:
        - name: source
          workspace: workspace
        - name: registry-auth
          workspace: registry-auth
    - name: secret-detection-detect-secrets
      taskRef:
        name: utils-task
      runAfter:
        - source-clone-repository
      params:
        - name: SCRIPT
          value: |
            #!/usr/bin/env bash
            echo "This is a placeholder for secret-detection-detect-secrets"

I think of Stages as being implemented by collections of TaskRuns in the Tekton world. Stages are more abstract and can be implemented by a single pipeline, a portion of a single pipeline, multiple pipelines, or portions of multiple pipelines. People talk about them all the time in talks and articles, but in reality, they're pretty complex.

[amfred]

In the example above, source-clone-repository and build-configure-build are usually considered part of the Build stage, while secret-detection-detect-secrets might be part of a Build or Test stage, depending on who you're talking to.

I might have my Deploy stage towards the end of this Tekton pipeline, or I might have it in a different Tekton pipeline that gets triggered after a new image is pushed to the image repository. And I could have some Tests early in the process (right after build) and some Tests later (after Deploy).

I think everyone knows what these stages are in the abstract, but they're hard to pin down when you get to the implementation level.

[e-backmark-ericsson]

I believe we will have a hard time aligning on new terms to be used for the 0.1 release, as it would require some substantial discussions and reviews on common terms, and I'd not like to delay the 0.1 release too much due to that. But I believe we should aim at setting a more thought through naming convention for 0.2.

The current names are quite connected to Tekton terms, as PipelineRuns and TaskRuns, and I believe we'd benefit from getting some kind of consensus from the Interop SIG on what terms to use when talking about the different columns in this table. SIG Events should be involved in that discussion, and we should aim for getting acceptance from most of the tools mentioned there so that we make sure the generic terms decided upon are understood by everyone involved. I don't at all think that the tools themselves need to rename their terms, but CDEvents should aim at using the terms defined by SIG Interop to be the generic terms.

Also, we'd need to be able to talk about "end-2-end pipelines" or "pipelines of pipelines" or "hierarchical pipelines", or similar, which is what @amfred talks about when it comes to pipelines triggered by (activities in) other pipelines.

[afrittoli]

For release v0.1.0 we will continue to use the existing terminology - we do want to align to the terminology defined by the SIG interoperability and we included this work as part of our roadmap after v0.1.0.

We will include a note in the "primer.md" document about how CDEvents terminology relates to work of the SIG interoperability.

[afrittoli]

Addressed the v0.1 part in https://github.com/cdevents/spec/pull/83