Add Go-SDK Agent Skills#239
Conversation
kaxil
left a comment
kaxil
left a comment
There was a problem hiding this comment.
These are well put together. The three-way split reads cleanly, the AFBNDL01 packing model comes across clearly, and the dependency-injection-by-type table plus the pitfalls/troubleshooting sections put the failure modes where a reader will hit them. Names, body lengths, and description lengths are all in good shape.
Both of the blocking issues trace back to #234. This PR adds skills/configuring-airflow-language-sdks/SKILL.md, and #234 adds a file at that same path with different content (Java-framed there, Go-inclusive here), so whichever merges second will conflict or overwrite the other. Several references here also point at skills that live only in #234 (authoring-language-sdk-tasks, the "read this first" foundation, plus authoring-java-sdk-tasks and deploying-java-sdk-bundles), so on main those links dangle. That is the same dead-cross-reference problem #237 set out to fix, whose stated check was that every cross-referenced skill resolves. Landing this after #234 (or together) and re-running that check against the combined tree clears both.
Lower-priority items, also noted inline: the @v1.0.0 pin won't resolve and reads as stable against the skill's own preview framing; the prose uses Dag/Dags while the rest of the catalog uses DAG; and the descriptions open imperative (Write/Configure/Build) where the post-#237 catalog settled on third-person-present (Writes/Configures/Builds), which is a consistency point rather than a rule. The trigger lists could also name a case or two where each skill should not fire, to cut misfires on generic "queue" questions.
| @@ -0,0 +1,136 @@ | |||
| --- | |||
| name: configuring-airflow-language-sdks | |||
| description: Configure Airflow to run language SDK tasks (Java, Go, and future native SDKs): register a coordinator, map a queue to it, ensure the runtime/artifact on workers, and tune coordinator options. Use when the user wants Airflow to route a queue to a native-language coordinator, asks about the `[sdk]` `coordinators`/`queue_to_coordinator` settings, `AIRFLOW__SDK__COORDINATORS`, `jars_root`/`executables_root` or other coordinator `kwargs`, `JavaCoordinator` or `ExecutableCoordinator`, `task_startup_timeout`, or why their native tasks aren't being picked up. Covers the shared routing mechanism plus per-coordinator options (JavaCoordinator, ExecutableCoordinator). | |||
There was a problem hiding this comment.
Merge collision: #234 also adds this exact path, and the two versions differ (its copy is Java-framed with JavaCoordinator/jars_root; this one is the Go-inclusive superset with ExecutableCoordinator/executables_root). Two open PRs can't both ADD the same file, so whichever lands second conflicts, and a careless resolution can silently drop one coordinator. Worth agreeing a merge order: land #234 first, then rebase this so the file becomes a MODIFY that adds the Go coordinator to #234's version.
|
|
||
| # Authoring Go SDK Tasks | ||
|
|
||
| The Airflow Go SDK implements the language-SDK model for Go: your Dag stays in Python, and each task is a compiled Go function registered inside a **bundle** (a single native executable). This skill covers the **Go-specific** native API. The shared model (the Python `@task.stub` pattern, ID matching, the XCom-as-JSON contract) lives in **authoring-language-sdk-tasks**; read that first if you are new to language SDKs. |
There was a problem hiding this comment.
authoring-language-sdk-tasks doesn't exist on main yet (it's introduced by the unmerged #234), so this "read that first" pointer is a dead link until #234 lands, and the skill isn't self-contained without it. The authoring-java-sdk-tasks and deploying-java-sdk-bundles references in configuring-airflow-language-sdks have the same problem. Gating this on #234, or landing them together, keeps every cross-reference resolvable, which is the check #237 introduced.
| @@ -0,0 +1,173 @@ | |||
| --- | |||
| name: authoring-go-sdk-tasks | |||
| description: Write Airflow task logic in Go using the Airflow Go SDK. Use when the user wants to implement Airflow tasks in Go, asks about `BundleProvider`/`RegisterDags`, the `bundlev1` Registry/Dag interfaces, registering Go tasks, dependency injection by parameter type (`context.Context`, `sdk.TIRunContext`, `*slog.Logger`, `sdk.Client`), reading connections/variables/XComs from Go, or `sdk.TIRunContext`. This skill covers the Go-specific native API; the shared Python-stub pattern and conceptual model live in authoring-language-sdk-tasks. For building/packing/shipping the bundle see deploying-go-sdk-bundles; for coordinator config see configuring-airflow-language-sdks. | |||
There was a problem hiding this comment.
Minor: sdk.TIRunContext is listed twice in the trigger description (in the DI-by-type parenthetical and again at the end). The second one is redundant and just spends trigger budget.
There was a problem hiding this comment.
Addressed the last two comments in ec49435. I will address rest of them once the Java-SDK one is merged.
3 participants
Same as #234 targeting for AIP-108 with 3.3.0 but focus on Go-SDK side.