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

Enable Outputs on a Workflow Level #2784

Open
ericmeadows opened this issue Apr 22, 2020 · 1 comment
Open

Enable Outputs on a Workflow Level #2784

ericmeadows opened this issue Apr 22, 2020 · 1 comment
Labels
area/spec Changes to the workflow specification. solution/workaround There's a workaround, might not be great, but exists type/feature Feature request

Comments

@ericmeadows
Copy link

Summary

Enable Workflows to have outputs that can be sourced from steps, including onExit, and can get values from nested Workflow Templates by their step names.

Motivation

I would like to understand what builds ran that had under 75% code coverage, which have high code smells (SonarLint/SonarQube), what my average build cost is per build per user (see #2783).

Proposal

I would like all builds to have outputs be enabled, and configurable.


Message from the maintainers:

If you wish to see this enhancement implemented please add a 👍 reaction to this issue! We often sort issues this way to know what to prioritize.

@ericmeadows ericmeadows added the type/feature Feature request label Apr 22, 2020
@louiscpalma
Copy link

louiscpalma commented Jul 6, 2020

I've been looking for similar functionality in Argo and ultimately resorted to using global outputs as a workaround. I don't believe this works for onExit steps though, and also becomes problematic with templated steps since they can't share the same globalName.

Luckily this is sufficient for my use-case right now, but can see this becoming a problem in the future:

Example Workflow

---
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  name: issue2748
  namespace: argo
spec:
  serviceAccountName: argo
  entrypoint: main
  onExit: exit-handler

  templates:
  - name: main
    steps:
    - - name: first
        template: sample
    - - name: second
        template: sample

  - name: sample
    container:
      image: debian:buster-slim
      command: [sh, -c]
      args: ['echo "some data from ${HOSTNAME}" |tee /tmp/data.txt']
    outputs: 
      parameters:
      - name: data
        valueFrom:
          path: /tmp/data.txt
        globalName: my-data

  - name: exit-handler
    container:
      image: debian:buster-slim
      command: [sh, -c]
      args: ['echo {{main.steps.first.outputs.parameters.data}}'] # Cannot find reference

### WORKAROUND ###      
# will be overwritten with main.second.outputs.parameters.data
# args: ['echo {{workflow.outputs.parameters.my-data}}']

Expected output

issue2748-4230798355: some data from issue2748-4230798355
issue2748-1574821332: some data from issue2748-1574821332
issue2748-1438237774: some data from issue2748-4230798355

Returned output

issue2748-4230798355: some data from issue2748-4230798355
issue2748-1574821332: some data from issue2748-1574821332
issue2748-1438237774: {{main.steps.first.output.parameters.data}}

@alexec alexec added area/spec Changes to the workflow specification. solution/workaround There's a workaround, might not be great, but exists labels Feb 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/spec Changes to the workflow specification. solution/workaround There's a workaround, might not be great, but exists type/feature Feature request
Projects
None yet
Development

No branches or pull requests

3 participants