6

What is the best way to trigger an argo workflow from an API request?

The API request is handled by a web server, how does the server submits the workflow to the argo server? Using the CLI? using a rest request? What is the best/recommended approach here?

crenshaw-dev
  • 7,504
  • 3
  • 45
  • 81
Moshe Shaham
  • 15,448
  • 22
  • 74
  • 114

1 Answers1

8

There's no one "right way." But here are some of the options, so you can pick the one that makes the most sense for your application:

  • Use the Argo API

    • with an SDK (Java, Go, Python)

      If your API is written in Java, Go, or Python, and if your interactions with Argo are more complex than simply submitting a Workflow (for example, if you're also listing Workflows and would like a nice representation of those objects), an Argo Workflows SDK might be a good choice. In my experience the SDKs have quirks and bugs, so I'd only dive in if you need a more full-featured client.

    • directly with some HTTP client

      If your use case is very simple (like submitting a small Workflow with a WorkflowTemplate reference), I would recommend using a direct HTTP call to the Argo or Kubernetes API.

  • Use a webhook

    The webhook endpoint is technically part of the API, but it's a bit different. The API is basically a specialized version of the Kubernetes API, tailored to the Argo CRDs. The events API endpoint provides some additional features specific to kicking off workflows.

  • Use the CLI

    You'd have to fork the CLI process from your server code, so this probably isn't the "cleanest" approach.

  • Use Argo Events

    Argo Events is a separate but closely-related project. It can accept a variety of inputs (webhooks, pub/sub messages, etc) and then trigger a Workflow.

    Argo Events could make sense if, for example, you want an external record of all the workflows submitted. Pub/sub would give you that record.

  • Use the Kubernetes API or CLI

    Workflows are just Kubernetes resources, so you can just submit them via Kubernetes mechanisms if you like. If your language has a robust Kubernetes SDK, that's a solid choice.

As I'm sure you can tell, it really depends on the application. Let me know if any of these needs clarification.

OneCricketeer
  • 179,855
  • 19
  • 132
  • 245
crenshaw-dev
  • 7,504
  • 3
  • 45
  • 81
  • Thanks, that's a very helpful overview of my options! I guess I'll start with simple API requests. – Moshe Shaham Jun 08 '21 at 17:29
  • @MosheShaham you bet! Yep, that seems like a reasonable way to start. – crenshaw-dev Jun 08 '21 at 17:34
  • Looking into source code, webhooks are hard-coded to only accept requests from github, gitlab, or bitbucket. – OneCricketeer Feb 03 '23 at 08:47
  • 1
    @OneCricketeer that code augments requests with an auth token in cases where the request originates from one of those SCMs. If the request carries its own token, or if the request is not a POST, it passes along unaltered. https://github.com/argoproj/argo-workflows/blob/898f0649fa15d8899a7561f3c1cf953a21dcf34f/server/auth/webhook/interceptor.go#L54 – crenshaw-dev Feb 03 '23 at 16:09
  • _if the request is not a POST_ - Well, I want to submit an event with a payload, so I need `POST` :) Okay, so the docs showing the `jenkins` service account are starting to make more sense. However, also looks like `-H 'Authorization: random'` will bypass that as well? What if I started the server with `auth-mode=server`? – OneCricketeer Feb 03 '23 at 20:33
  • 1
    @OneCricketeer looks to me like if you want to send a POST, you either have to populate the `Authorization` header, or you have to create a `argo-workflows-webhook-clients` with an empty `data` field so you can bypass the SCM-specific auth code. – crenshaw-dev Feb 03 '23 at 22:56