Add kind that demonstrates how to modify the upstream graph in a transform #438
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a very rough prototype for what's been discussed in #417 and taskcluster/taskgraph#424. In this example, the decision about which tasks
merge-corpus
should depend on are being deferred and handled in the newmodify_graph
transform, which runs as part of themodify-graph
task that happens right beforeall
.Because we're handling the
dependencies
later, we must also handle thefetches
later - which means that knowledge about those artifact names moves out of themerge-corpus
kind and into this transform.I haven't tested this besides some
taskgraph full -Y
inspection, but it looks plausible - and the code certainly runs at the appropriate time, and has access to the necessary data to make the changes.Any tasks that you need to modify or access must be in a kind listed in the
modify-graph
kind'skind-dependencies
, otherwise they will not show up inconfig.kind_dependencies.tasks
.And at the risk of being annoying and repeating myself, I will offer a couple of cautions: