dheerajturaga commented on PR #69148:
URL: https://github.com/apache/airflow/pull/69148#issuecomment-4976465254
Thanks for the feedback, both points landed. Proposal to address them:
Instead of three flat parameters (which would keep growing — I also want
task-level scoping), collapse everything into a **single optional `applies_to`
object**:
```python
"applies_to": {
"dag_tags": ["ml"], # Dag carries any of these tags
"dag_ids": ["train_pipeline"], # exact dag_id
"task_ids": ["train_model"], # exact task_id
"operators": ["KubernetesPodOperator"], # task's operator class
}
```
Semantics like Kubernetes label selectors: **OR within a key, AND across
keys**, omit `applies_to` entirely → tab shows everywhere (current behavior).
I'm dropping `dag_id_pattern` — glob matching was the most bespoke part and I
don't need it.
On the concerns raised:
- *API sprawl*: the schema gains exactly one field, ever. Future criteria
become keys inside one model rather than new top-level parameters.
- *Dependency direction*: `dag_tags` puts the opt-in on the Dag side (the
Dag author tags their Dag to receive the tab), and `operators` is the case
where the plugin legitimately knows what it applies to — a plugin built for a
specific operator. `dag_ids` and `task_ids` round it out as exact-match
criteria for plugins tied to a specific Dag or task.
I'd also split the "pass `dag` (and task/TI) context to React app plugins"
change into a separate PR, since it's independent and useful for self-contained
plugins regardless.
If this shape looks reasonable I'll rework the branch.
---
Drafted-by: Claude Code (Fable 5); reviewed by @dheerajturaga before posting
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
