Bug 1635525 Comment 6 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Note to self: I found one of the issues as to why we ended up with this. Most of my testing in preparation for this was done via `taskgraph target-task` and params.yml  for each of the promotion phases. I completely missed the fact that partials are coming from Ship-it which builds the AC and sets those up inte AC payload, which then at runtime, bakes those in environment variable [here](https://hg.mozilla.org/mozilla-central/file/tip/taskcluster/taskgraph/actions/release_promotion.py#l260) so that when we run the taskgraph to build the rest of the graph we find them in env vars and bake them in the `release_config` [here[(https://hg.mozilla.org/mozilla-central/file/tip/taskcluster/taskgraph/util/scriptworker.py#l315). Because locally that's empty, I never actually tested that part.  Also, note that `nazgul` jobs are missing from https://hg.mozilla.org/mozilla-central/file/tip/taskcluster/taskgraph/util/scriptworker.py#l316. So had I tested this right, I would've noticed that vanilla bouncer jobs are generating the partials entries while the nazgul jobs don't. I need to update that there. 

TIL for me:
* when testing against AC tasks, I should use the `taskgraph action-callback` as opposed to `taskgraph target-graph`
* I should've grepped bouncer entries in all tree, not just duplicating the existing jobs. Vanilla bouncer jobs appear as dep tasks, if conditions, etc.
Note to self: found one of the issues as to why we ended up with this. Most of my testing in preparation for this was done via `taskgraph target-task` and params.yml  for each of the promotion phases. I completely missed the fact that partials are coming from Ship-it which builds the AC task and sets those up in the payload, which then at runtime, bakes those in environment variable [here](https://hg.mozilla.org/mozilla-central/file/tip/taskcluster/taskgraph/actions/release_promotion.py#l260) so that when we run the taskgraph to build the rest of the graph we find them in the `release_config` [here](https://hg.mozilla.org/mozilla-central/file/tip/taskcluster/taskgraph/util/scriptworker.py#l315). Because locally that's empty, I never actually tested that part.  Also, note that `nazgul` jobs are missing from https://hg.mozilla.org/mozilla-central/file/tip/taskcluster/taskgraph/util/scriptworker.py#l316. Had I tested this right, I would've noticed that vanilla bouncer jobs are generating the partials entries while the nazgul jobs don't. I need to update that there. 

TIL for me:
* when testing against AC tasks, I should use the `taskgraph action-callback` as opposed to `taskgraph target-graph`
* I should've grepped bouncer entries in all tree, not just duplicating the existing jobs. Vanilla bouncer jobs appear as dep tasks, if conditions, etc.
Note to self: found one of the issues as to why we ended up with this. Most of my testing in preparation for this was done via `taskgraph target-task` and params.yml  for each of the promotion phases. I completely missed the fact that partials are coming from Ship-it which builds the AC task and sets those up in the payload, which then at runtime, bakes those in environment variable [here](https://hg.mozilla.org/mozilla-central/file/tip/taskcluster/taskgraph/actions/release_promotion.py#l260) so that when we run the taskgraph to build the rest of the graph we find them in the `release_config` [here](https://hg.mozilla.org/mozilla-central/file/tip/taskcluster/taskgraph/util/scriptworker.py#l315). Because locally that's empty, I never actually tested that part.  Also, note that `nazgul` jobs are missing from https://hg.mozilla.org/mozilla-central/file/tip/taskcluster/taskgraph/util/scriptworker.py#l316. Had I tested this right, I would've noticed that vanilla bouncer jobs are generating the partials entries while the nazgul jobs don't. I need to update that there. 

TIL for me:
* when testing against AC tasks, I should use the `taskgraph action-callback` as opposed to `taskgraph target-graph`
e.g. 
```
./mach taskgraph test-action-callback —verbose —task-group-id <decision-task-id-to-promote> —input action_input.json (taken from AC task extra payload) release-promotion > dirty_action_callback.json

```
* I should've grepped bouncer entries in all tree, not just duplicating the existing jobs. Vanilla bouncer jobs appear as dep tasks, if conditions, etc.

Back to Bug 1635525 Comment 6