Add example of how to use publish and publish-on-error attributes #6
Conversation
| # It's used here to keep the code D.R.Y. That is, instead of declaring the same variables | ||
| # again in the publish-on-error block, we dereference the variables using an asterisk (*). |
There was a problem hiding this comment.
I get what this is saying, but I worry that people unfamiliar with clean code practices might not
| # It's used here to keep the code D.R.Y. That is, instead of declaring the same variables | |
| # again in the publish-on-error block, we dereference the variables using an asterisk (*). | |
| # It's used here to keep the code "D.R.Y." (Don't Repeat Yourself) That is, instead of declaring the same variables | |
| # again in the publish-on-error block, we dereference the variables using an asterisk (*). |
| job_name: task_1 | ||
| job_id: <% task(task_1).result.job_id %> | ||
| run_id: <% task(task_1).result.run_id %> | ||
| started_at: <% task(task_1).result.started_at %> | ||
| finished_at: <% task(task_1).result.finished_at %> | ||
| status: <% task(task_1).result.state %> |
There was a problem hiding this comment.
I've always wondered what sort of task information is available to be publish'ed like this -- is it just these fields? Could you add a link to the docs?
| job_name: task_2 | ||
| job_id: <% task(task_2).result.job_id %> | ||
| run_id: <% task(task_2).result.run_id %> | ||
| started_at: <% task(task_2).result.started_at %> | ||
| finished_at: <% task(task_2).result.finished_at %> | ||
| status: <% task(task_2).result.state %> |
There was a problem hiding this comment.
Could you clarify whether this will overwrite the previous values of these variables?
There was a problem hiding this comment.
I believe it will. I'm not sure that's a paradigm we want to recommend? One thing that might be useful for overwriting is if there's a workflow input field that you want a task to overwrite. I believe then you can use the input if you want to run a partial workflow.
| job_name: task_2 | ||
| job_id: <% task(task_2).result.job_id %> | ||
| run_id: <% task(task_2).result.run_id %> | ||
| started_at: <% task(task_2).result.started_at %> | ||
| finished_at: <% task(task_2).result.finished_at %> | ||
| status: <% task(task_2).result.state %> |
There was a problem hiding this comment.
I believe it will. I'm not sure that's a paradigm we want to recommend? One thing that might be useful for overwriting is if there's a workflow input field that you want a task to overwrite. I believe then you can use the input if you want to run a partial workflow.
| input: | ||
| source: | | ||
| print( | ||
| 'Job Name: <% $.job_name %>\n' |
There was a problem hiding this comment.
I'm doing this in another example, but I think we should set the example of setting up script inputs, passing these in as parameters, and accessing them through python's os.environ. But if this is less confusing that works.
|
|
||
| time.sleep(5) | ||
| print('Task 1') | ||
| time.sleep(5) |
There was a problem hiding this comment.
Would it be helpful to folk to have this script create a JSON output and publish that, or is that too confusing? Maybe it does make sense to focus on publish here, and we have another example of a JSON output that they can combine.
|
We've changed the default branch to |
Add example workflow that shows how to use both the publish and publish-on-error attributes of a task.