future.md

Duck types

The new app stack architecture relies heavily on the use of duck types throughout the system.

But what if the user wants to user a 3rd party tool that doesn't conform to the duck-type.

Exposing custom status

We want to let workflows expose a custom status so they can act like any duck-type.

latestCommit, latestImage, latestRevisionRefs, or anything else.

apiVersion: experimental.kontinue.io/v1
kind: WorkflowTemplate
metadata:
  name: template
spec:
  sources:
    - repo
    - golang
    
  outputs:                                     #<================ run outputs
    - name: commit
      valueFrom:
        output:
          step: unit
          name: commit

  steps:
    - name: unit 
      sources: [repo, golang]
      outputs:                          
        - name: commit
          objectFrom:                          #<================ step outputs
            - name: url
              valueFrom:
                template:
                  jsonPath: '{.status.results[0].url}'
            - name: sha
              valueFrom:
                template:
                  jsonPath: '{.status.results[0].sha}'
      templates:
        - template:
            apiVersion: tekton.dev/v1beta1
            kind: TaskRun
            metadata:
              generateName: 'app-unit-'
            spec:
              serviceAccountName: example-app-sa
              taskRef:
                name: unit-tests
              params:
                - name: git-url
                  value: '{{ .Sources.repo.url }}'                   
                - name: git-revision
                  value: '{{ .Sources.repo.revision }}'
                - name: image
                  value: '{{ .Sources.golang.url }}@{{ .Sources.golang.revision }}'    

---

kind: Workflow
metadata:
  name: my-workflow
spec:

  workflowTemplateRef:
    name: template
    
  sources:
    - name: repo
      sourceRefs: [.]

  exposing:
    - name: latestCommit
      valueFrom:
        output:
          name: commit                    # <===================== output from run
          select: LATEST                  # <===================== WUT?
          
status:
  latestCommit:                           # <===================== exposed directly under status
    url: github.com/some/repo
    sha: sha-111

Difficulties

Latest

We are operating on our history of workflow runs.

LATEST, MAX, MIN, COUNT

Grouping

Different versions provide different ways that workflow runs should be grouped.

  commits -> grouped by branch
  digests -> grouped by tag

apiVersion: experimental.kontinue.io/v1
kind: GitSource
metadata:
  name: repo
spec:
  url: github.com/some/repo                               
  branchFilter: 'feature/*'               # <===================== all feature branches

---

kind: Workflow
metadata:
  name: my-workflow
spec:
  sources:
    - name: repo
      sourceRefs: [..]                    
          
status:
  latestCommits:                          # <===================== you probably want to track multiple commits
    - url: github.com/some/repo
      sha: sha-1                          # feature/a                         
    - url: github.com/some/repo
      sha: sha-2                          # feature/b                         

But maybe things change under different circumstances:

kind: Workflow
metadata:
  name: my-workflow
spec:
  sources:
    - name: repo                          # <===================== tracking: [prod, staging]
      sourceRefs: [..]                    

status:
  latestCommit:                           # <===================== only expose 'prod' commit
    url: github.com/some/repo
    sha: sha-1

So we probably want a way of filtering:

kind: Workflow
metadata:
  name: my-workflow
spec:            

  exposing:
    - name: latestCommit
      valueFrom:
        output:
          name: commit
          select: LATEST
          branch: prod                      # <===================== XXXX nope
          filter: {.branch == prod}         # <===================== need to be generic

Proposal

We've been contemplating a few different options here: https://gitlab.eng.vmware.com/tanzu-delivery-pipeline/workflow-controller/-/issues/41

And our frontrunner seems to be this solution: https://gitlab.eng.vmware.com/tanzu-delivery-pipeline/workflow-controller/-/issues/41#note_5097770