mirror of
https://github.com/windmill-labs/windmill.git
synced 2026-10-12 16:02:56 +00:00
fix: carry the no-type rule into flow inputs and script parameters, and ask the chat to relay the sync
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
co-authored by
Claude Opus 5.5
parent
51934ef478
commit
75c8b20845
@@ -16,6 +16,15 @@
|
||||
- "the main step is named `sum_numbers`"
|
||||
- the flow returns the sum of the two numbers
|
||||
|
||||
# An in-house API has no hub resource type: the connection still comes in as one resource, not
|
||||
# a token input or a variable read inside the code.
|
||||
- id: flow-resource-type-custom-api
|
||||
prompt: |-
|
||||
Create a flow that fetches an invoice by id from our internal billing API at https://billing.acme.internal/api/v1. It authenticates with a bearer token.
|
||||
judgeChecklist:
|
||||
- the flow takes the billing API's base URL and token together as one resource-typed input, not a plain string token or a variable read inside the code
|
||||
- the flow fetches an invoice by id with a bearer token
|
||||
|
||||
- id: flow-test1-reuse-existing-script
|
||||
prompt: |-
|
||||
I need a flow that adds two numbers.
|
||||
|
||||
@@ -13,6 +13,16 @@
|
||||
- returns a plain greeting string
|
||||
- does not wrap the result in an object or array
|
||||
|
||||
# An in-house API has no hub resource type: the connection still comes in as one resource, not
|
||||
# a token parameter or a variable read inside the code.
|
||||
- id: script-resource-type-custom-api
|
||||
prompt: |-
|
||||
Update the current Bun script so it fetches an invoice by id from our internal billing API at https://billing.acme.internal/api/v1. It authenticates with a bearer token.
|
||||
initial: ai_evals/fixtures/frontend/script/initial/test1_empty_bun.json
|
||||
judgeChecklist:
|
||||
- the script takes the billing API's base URL and token together as one resource-typed parameter, not a plain string token or a variable read inside the code
|
||||
- the script fetches an invoice by id with a bearer token
|
||||
|
||||
- id: script-test2-create-current-script-schedule
|
||||
prompt: |-
|
||||
Update the current Bun script so it takes the existing `name` input and returns a plain greeting string like `Hello, Alice!`.
|
||||
|
||||
Generated
+28
-20
@@ -95,7 +95,7 @@ Use \`wmill resource-type list --schema\` to discover available resource types.
|
||||
## General Principles
|
||||
|
||||
- A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
|
||||
- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
|
||||
- When no resource type exists for a service, still take its connection as one resource-typed parameter, of a type holding the connection fields (base URL, account identifiers, credentials), its secret in a variable the resource references. A plain string parameter or a variable read inside the code only when the user asks for it: the resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose the resource type and ask before creating it
|
||||
- Libraries are installed automatically - do not show installation instructions
|
||||
- In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it \`main\` (\`Main\` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no \`main\`: their language section shows how they take arguments
|
||||
- Where the language has a Windmill client (\`wmill\`), use it to interact with the platform
|
||||
@@ -260,7 +260,7 @@ Use \`wmill resource-type list --schema\` to discover available resource types.
|
||||
## General Principles
|
||||
|
||||
- A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
|
||||
- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
|
||||
- When no resource type exists for a service, still take its connection as one resource-typed parameter, of a type holding the connection fields (base URL, account identifiers, credentials), its secret in a variable the resource references. A plain string parameter or a variable read inside the code only when the user asks for it: the resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose the resource type and ask before creating it
|
||||
- Libraries are installed automatically - do not show installation instructions
|
||||
- In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it \`main\` (\`Main\` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no \`main\`: their language section shows how they take arguments
|
||||
- Where the language has a Windmill client (\`wmill\`), use it to interact with the platform
|
||||
@@ -385,7 +385,7 @@ Use \`wmill resource-type list --schema\` to discover available resource types.
|
||||
## General Principles
|
||||
|
||||
- A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
|
||||
- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
|
||||
- When no resource type exists for a service, still take its connection as one resource-typed parameter, of a type holding the connection fields (base URL, account identifiers, credentials), its secret in a variable the resource references. A plain string parameter or a variable read inside the code only when the user asks for it: the resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose the resource type and ask before creating it
|
||||
- Libraries are installed automatically - do not show installation instructions
|
||||
- In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it \`main\` (\`Main\` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no \`main\`: their language section shows how they take arguments
|
||||
- Where the language has a Windmill client (\`wmill\`), use it to interact with the platform
|
||||
@@ -503,7 +503,7 @@ Use \`wmill resource-type list --schema\` to discover available resource types.
|
||||
## General Principles
|
||||
|
||||
- A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
|
||||
- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
|
||||
- When no resource type exists for a service, still take its connection as one resource-typed parameter, of a type holding the connection fields (base URL, account identifiers, credentials), its secret in a variable the resource references. A plain string parameter or a variable read inside the code only when the user asks for it: the resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose the resource type and ask before creating it
|
||||
- Libraries are installed automatically - do not show installation instructions
|
||||
- In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it \`main\` (\`Main\` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no \`main\`: their language section shows how they take arguments
|
||||
- Where the language has a Windmill client (\`wmill\`), use it to interact with the platform
|
||||
@@ -1327,7 +1327,7 @@ Use \`wmill resource-type list --schema\` to discover available resource types.
|
||||
## General Principles
|
||||
|
||||
- A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
|
||||
- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
|
||||
- When no resource type exists for a service, still take its connection as one resource-typed parameter, of a type holding the connection fields (base URL, account identifiers, credentials), its secret in a variable the resource references. A plain string parameter or a variable read inside the code only when the user asks for it: the resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose the resource type and ask before creating it
|
||||
- Libraries are installed automatically - do not show installation instructions
|
||||
- In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it \`main\` (\`Main\` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no \`main\`: their language section shows how they take arguments
|
||||
- Where the language has a Windmill client (\`wmill\`), use it to interact with the platform
|
||||
@@ -2163,7 +2163,7 @@ Use \`wmill resource-type list --schema\` to discover available resource types.
|
||||
## General Principles
|
||||
|
||||
- A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
|
||||
- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
|
||||
- When no resource type exists for a service, still take its connection as one resource-typed parameter, of a type holding the connection fields (base URL, account identifiers, credentials), its secret in a variable the resource references. A plain string parameter or a variable read inside the code only when the user asks for it: the resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose the resource type and ask before creating it
|
||||
- Libraries are installed automatically - do not show installation instructions
|
||||
- In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it \`main\` (\`Main\` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no \`main\`: their language section shows how they take arguments
|
||||
- Where the language has a Windmill client (\`wmill\`), use it to interact with the platform
|
||||
@@ -2280,7 +2280,7 @@ Use \`wmill resource-type list --schema\` to discover available resource types.
|
||||
## General Principles
|
||||
|
||||
- A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
|
||||
- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
|
||||
- When no resource type exists for a service, still take its connection as one resource-typed parameter, of a type holding the connection fields (base URL, account identifiers, credentials), its secret in a variable the resource references. A plain string parameter or a variable read inside the code only when the user asks for it: the resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose the resource type and ask before creating it
|
||||
- Libraries are installed automatically - do not show installation instructions
|
||||
- In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it \`main\` (\`Main\` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no \`main\`: their language section shows how they take arguments
|
||||
- Where the language has a Windmill client (\`wmill\`), use it to interact with the platform
|
||||
@@ -3106,7 +3106,7 @@ Use \`wmill resource-type list --schema\` to discover available resource types.
|
||||
## General Principles
|
||||
|
||||
- A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
|
||||
- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
|
||||
- When no resource type exists for a service, still take its connection as one resource-typed parameter, of a type holding the connection fields (base URL, account identifiers, credentials), its secret in a variable the resource references. A plain string parameter or a variable read inside the code only when the user asks for it: the resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose the resource type and ask before creating it
|
||||
- Libraries are installed automatically - do not show installation instructions
|
||||
- In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it \`main\` (\`Main\` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no \`main\`: their language section shows how they take arguments
|
||||
- Where the language has a Windmill client (\`wmill\`), use it to interact with the platform
|
||||
@@ -3257,7 +3257,7 @@ Use \`wmill resource-type list --schema\` to discover available resource types.
|
||||
## General Principles
|
||||
|
||||
- A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
|
||||
- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
|
||||
- When no resource type exists for a service, still take its connection as one resource-typed parameter, of a type holding the connection fields (base URL, account identifiers, credentials), its secret in a variable the resource references. A plain string parameter or a variable read inside the code only when the user asks for it: the resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose the resource type and ask before creating it
|
||||
- Libraries are installed automatically - do not show installation instructions
|
||||
- In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it \`main\` (\`Main\` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no \`main\`: their language section shows how they take arguments
|
||||
- Where the language has a Windmill client (\`wmill\`), use it to interact with the platform
|
||||
@@ -3391,7 +3391,7 @@ Use \`wmill resource-type list --schema\` to discover available resource types.
|
||||
## General Principles
|
||||
|
||||
- A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
|
||||
- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
|
||||
- When no resource type exists for a service, still take its connection as one resource-typed parameter, of a type holding the connection fields (base URL, account identifiers, credentials), its secret in a variable the resource references. A plain string parameter or a variable read inside the code only when the user asks for it: the resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose the resource type and ask before creating it
|
||||
- Libraries are installed automatically - do not show installation instructions
|
||||
- In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it \`main\` (\`Main\` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no \`main\`: their language section shows how they take arguments
|
||||
- Where the language has a Windmill client (\`wmill\`), use it to interact with the platform
|
||||
@@ -3512,7 +3512,7 @@ Use \`wmill resource-type list --schema\` to discover available resource types.
|
||||
## General Principles
|
||||
|
||||
- A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
|
||||
- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
|
||||
- When no resource type exists for a service, still take its connection as one resource-typed parameter, of a type holding the connection fields (base URL, account identifiers, credentials), its secret in a variable the resource references. A plain string parameter or a variable read inside the code only when the user asks for it: the resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose the resource type and ask before creating it
|
||||
- Libraries are installed automatically - do not show installation instructions
|
||||
- In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it \`main\` (\`Main\` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no \`main\`: their language section shows how they take arguments
|
||||
- Where the language has a Windmill client (\`wmill\`), use it to interact with the platform
|
||||
@@ -3626,7 +3626,7 @@ Use \`wmill resource-type list --schema\` to discover available resource types.
|
||||
## General Principles
|
||||
|
||||
- A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
|
||||
- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
|
||||
- When no resource type exists for a service, still take its connection as one resource-typed parameter, of a type holding the connection fields (base URL, account identifiers, credentials), its secret in a variable the resource references. A plain string parameter or a variable read inside the code only when the user asks for it: the resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose the resource type and ask before creating it
|
||||
- Libraries are installed automatically - do not show installation instructions
|
||||
- In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it \`main\` (\`Main\` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no \`main\`: their language section shows how they take arguments
|
||||
- Where the language has a Windmill client (\`wmill\`), use it to interact with the platform
|
||||
@@ -3743,7 +3743,7 @@ Use \`wmill resource-type list --schema\` to discover available resource types.
|
||||
## General Principles
|
||||
|
||||
- A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
|
||||
- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
|
||||
- When no resource type exists for a service, still take its connection as one resource-typed parameter, of a type holding the connection fields (base URL, account identifiers, credentials), its secret in a variable the resource references. A plain string parameter or a variable read inside the code only when the user asks for it: the resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose the resource type and ask before creating it
|
||||
- Libraries are installed automatically - do not show installation instructions
|
||||
- In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it \`main\` (\`Main\` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no \`main\`: their language section shows how they take arguments
|
||||
- Where the language has a Windmill client (\`wmill\`), use it to interact with the platform
|
||||
@@ -3861,7 +3861,7 @@ Use \`wmill resource-type list --schema\` to discover available resource types.
|
||||
## General Principles
|
||||
|
||||
- A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
|
||||
- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
|
||||
- When no resource type exists for a service, still take its connection as one resource-typed parameter, of a type holding the connection fields (base URL, account identifiers, credentials), its secret in a variable the resource references. A plain string parameter or a variable read inside the code only when the user asks for it: the resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose the resource type and ask before creating it
|
||||
- Libraries are installed automatically - do not show installation instructions
|
||||
- In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it \`main\` (\`Main\` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no \`main\`: their language section shows how they take arguments
|
||||
- Where the language has a Windmill client (\`wmill\`), use it to interact with the platform
|
||||
@@ -3994,7 +3994,7 @@ Use \`wmill resource-type list --schema\` to discover available resource types.
|
||||
## General Principles
|
||||
|
||||
- A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
|
||||
- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
|
||||
- When no resource type exists for a service, still take its connection as one resource-typed parameter, of a type holding the connection fields (base URL, account identifiers, credentials), its secret in a variable the resource references. A plain string parameter or a variable read inside the code only when the user asks for it: the resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose the resource type and ask before creating it
|
||||
- Libraries are installed automatically - do not show installation instructions
|
||||
- In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it \`main\` (\`Main\` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no \`main\`: their language section shows how they take arguments
|
||||
- Where the language has a Windmill client (\`wmill\`), use it to interact with the platform
|
||||
@@ -4110,7 +4110,7 @@ Use \`wmill resource-type list --schema\` to discover available resource types.
|
||||
## General Principles
|
||||
|
||||
- A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
|
||||
- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
|
||||
- When no resource type exists for a service, still take its connection as one resource-typed parameter, of a type holding the connection fields (base URL, account identifiers, credentials), its secret in a variable the resource references. A plain string parameter or a variable read inside the code only when the user asks for it: the resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose the resource type and ask before creating it
|
||||
- Libraries are installed automatically - do not show installation instructions
|
||||
- In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it \`main\` (\`Main\` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no \`main\`: their language section shows how they take arguments
|
||||
- Where the language has a Windmill client (\`wmill\`), use it to interact with the platform
|
||||
@@ -4241,7 +4241,7 @@ Use \`wmill resource-type list --schema\` to discover available resource types.
|
||||
## General Principles
|
||||
|
||||
- A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
|
||||
- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
|
||||
- When no resource type exists for a service, still take its connection as one resource-typed parameter, of a type holding the connection fields (base URL, account identifiers, credentials), its secret in a variable the resource references. A plain string parameter or a variable read inside the code only when the user asks for it: the resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose the resource type and ask before creating it
|
||||
- Libraries are installed automatically - do not show installation instructions
|
||||
- In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it \`main\` (\`Main\` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no \`main\`: their language section shows how they take arguments
|
||||
- Where the language has a Windmill client (\`wmill\`), use it to interact with the platform
|
||||
@@ -5251,7 +5251,7 @@ Use \`wmill resource-type list --schema\` to discover available resource types.
|
||||
## General Principles
|
||||
|
||||
- A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
|
||||
- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
|
||||
- When no resource type exists for a service, still take its connection as one resource-typed parameter, of a type holding the connection fields (base URL, account identifiers, credentials), its secret in a variable the resource references. A plain string parameter or a variable read inside the code only when the user asks for it: the resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose the resource type and ask before creating it
|
||||
- Libraries are installed automatically - do not show installation instructions
|
||||
- In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it \`main\` (\`Main\` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no \`main\`: their language section shows how they take arguments
|
||||
- Where the language has a Windmill client (\`wmill\`), use it to interact with the platform
|
||||
@@ -5412,7 +5412,7 @@ Use \`wmill resource-type list --schema\` to discover available resource types.
|
||||
## General Principles
|
||||
|
||||
- A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
|
||||
- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
|
||||
- When no resource type exists for a service, still take its connection as one resource-typed parameter, of a type holding the connection fields (base URL, account identifiers, credentials), its secret in a variable the resource references. A plain string parameter or a variable read inside the code only when the user asks for it: the resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose the resource type and ask before creating it
|
||||
- Libraries are installed automatically - do not show installation instructions
|
||||
- In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it \`main\` (\`Main\` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no \`main\`: their language section shows how they take arguments
|
||||
- Where the language has a Windmill client (\`wmill\`), use it to interact with the platform
|
||||
@@ -5563,7 +5563,7 @@ Use \`wmill resource-type list --schema\` to discover available resource types.
|
||||
## General Principles
|
||||
|
||||
- A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
|
||||
- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
|
||||
- When no resource type exists for a service, still take its connection as one resource-typed parameter, of a type holding the connection fields (base URL, account identifiers, credentials), its secret in a variable the resource references. A plain string parameter or a variable read inside the code only when the user asks for it: the resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose the resource type and ask before creating it
|
||||
- Libraries are installed automatically - do not show installation instructions
|
||||
- In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it \`main\` (\`Main\` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no \`main\`: their language section shows how they take arguments
|
||||
- Where the language has a Windmill client (\`wmill\`), use it to interact with the platform
|
||||
@@ -6299,6 +6299,14 @@ In the flow schema, set the property type to \`"object"\` with format \`"resourc
|
||||
}
|
||||
\`\`\`
|
||||
|
||||
### When No Resource Type Fits
|
||||
|
||||
A connection still comes in as one resource input, not as separate string inputs (a URL, a token) or a variable read inside a step: type the input \`resource-<name>\` with a resource type holding the service's connection fields, its secret in a variable the resource references.
|
||||
|
||||
- If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services.
|
||||
- Otherwise, or when the user prefers it to syncing, propose the resource type and ask before creating it.
|
||||
- A plain variable is fine when the user asks for it.
|
||||
|
||||
### As Step Input (Static Reference)
|
||||
|
||||
Reference a specific resource using \`$res:\` prefix:
|
||||
|
||||
@@ -1712,7 +1712,7 @@ function parseResourceTypeSchema(schema: unknown): unknown {
|
||||
}
|
||||
|
||||
export const HUB_SYNC_INSTRUCTIONS =
|
||||
'A superadmin can sync resource types from the hub with "Sync resource types with Hub" in the Add resource dialog of the Resources page.'
|
||||
'Tell the user: no resource of a missing type can be created until a superadmin syncs resource types from the hub, with "Sync resource types with Hub" in the Add resource dialog of the Resources page.'
|
||||
|
||||
async function missingResourceTypesNote(
|
||||
workspace: string,
|
||||
|
||||
@@ -582,6 +582,15 @@ In the flow schema, set the property type to `"object"` with format `"resource-{
|
||||
}
|
||||
```
|
||||
|
||||
### When No Resource Type Fits
|
||||
|
||||
A connection still comes in as one resource input, not as separate string inputs (a URL, a token) or a variable read inside a step: type the input `resource-<name>` with a resource type holding the service's connection fields, its secret in a variable the resource references.
|
||||
|
||||
- If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services.
|
||||
- Otherwise, or when the user prefers it to syncing, propose the resource type and ask before creating it.
|
||||
- Where you have no way to create a resource type yourself, give the user the schema to add with **Add resource type** on the Resources page.
|
||||
- A plain variable is fine when the user asks for it.
|
||||
|
||||
### As Step Input (Static Reference)
|
||||
|
||||
Reference a specific resource using `$res:` prefix:
|
||||
|
||||
@@ -5,7 +5,7 @@ export const SCRIPT_BASE = `# Windmill Script Writing Guide
|
||||
## General Principles
|
||||
|
||||
- A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
|
||||
- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
|
||||
- When no resource type exists for a service, still take its connection as one resource-typed parameter, of a type holding the connection fields (base URL, account identifiers, credentials), its secret in a variable the resource references. A plain string parameter or a variable read inside the code only when the user asks for it: the resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose the resource type and ask before creating it
|
||||
- Libraries are installed automatically - do not show installation instructions
|
||||
- In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it \`main\` (\`Main\` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no \`main\`: their language section shows how they take arguments
|
||||
- Where the language has a Windmill client (\`wmill\`), use it to interact with the platform
|
||||
@@ -610,6 +610,15 @@ In the flow schema, set the property type to \`"object"\` with format \`"resourc
|
||||
}
|
||||
\`\`\`
|
||||
|
||||
### When No Resource Type Fits
|
||||
|
||||
A connection still comes in as one resource input, not as separate string inputs (a URL, a token) or a variable read inside a step: type the input \`resource-<name>\` with a resource type holding the service's connection fields, its secret in a variable the resource references.
|
||||
|
||||
- If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services.
|
||||
- Otherwise, or when the user prefers it to syncing, propose the resource type and ask before creating it.
|
||||
- Where you have no way to create a resource type yourself, give the user the schema to add with **Add resource type** on the Resources page.
|
||||
- A plain variable is fine when the user asks for it.
|
||||
|
||||
### As Step Input (Static Reference)
|
||||
|
||||
Reference a specific resource using \`$res:\` prefix:
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
## General Principles
|
||||
|
||||
- A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
|
||||
- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
|
||||
- When no resource type exists for a service, still take its connection as one resource-typed parameter, of a type holding the connection fields (base URL, account identifiers, credentials), its secret in a variable the resource references. A plain string parameter or a variable read inside the code only when the user asks for it: the resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose the resource type and ask before creating it
|
||||
- Libraries are installed automatically - do not show installation instructions
|
||||
- In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it `main` (`Main` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no `main`: their language section shows how they take arguments
|
||||
- Where the language has a Windmill client (`wmill`), use it to interact with the platform
|
||||
|
||||
@@ -671,6 +671,14 @@ In the flow schema, set the property type to `"object"` with format `"resource-{
|
||||
}
|
||||
```
|
||||
|
||||
### When No Resource Type Fits
|
||||
|
||||
A connection still comes in as one resource input, not as separate string inputs (a URL, a token) or a variable read inside a step: type the input `resource-<name>` with a resource type holding the service's connection fields, its secret in a variable the resource references.
|
||||
|
||||
- If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services.
|
||||
- Otherwise, or when the user prefers it to syncing, propose the resource type and ask before creating it.
|
||||
- A plain variable is fine when the user asks for it.
|
||||
|
||||
### As Step Input (Static Reference)
|
||||
|
||||
Reference a specific resource using `$res:` prefix:
|
||||
|
||||
@@ -53,7 +53,7 @@ Use `wmill resource-type list --schema` to discover available resource types.
|
||||
## General Principles
|
||||
|
||||
- A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
|
||||
- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
|
||||
- When no resource type exists for a service, still take its connection as one resource-typed parameter, of a type holding the connection fields (base URL, account identifiers, credentials), its secret in a variable the resource references. A plain string parameter or a variable read inside the code only when the user asks for it: the resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose the resource type and ask before creating it
|
||||
- Libraries are installed automatically - do not show installation instructions
|
||||
- In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it `main` (`Main` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no `main`: their language section shows how they take arguments
|
||||
- Where the language has a Windmill client (`wmill`), use it to interact with the platform
|
||||
|
||||
@@ -53,7 +53,7 @@ Use `wmill resource-type list --schema` to discover available resource types.
|
||||
## General Principles
|
||||
|
||||
- A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
|
||||
- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
|
||||
- When no resource type exists for a service, still take its connection as one resource-typed parameter, of a type holding the connection fields (base URL, account identifiers, credentials), its secret in a variable the resource references. A plain string parameter or a variable read inside the code only when the user asks for it: the resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose the resource type and ask before creating it
|
||||
- Libraries are installed automatically - do not show installation instructions
|
||||
- In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it `main` (`Main` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no `main`: their language section shows how they take arguments
|
||||
- Where the language has a Windmill client (`wmill`), use it to interact with the platform
|
||||
|
||||
@@ -53,7 +53,7 @@ Use `wmill resource-type list --schema` to discover available resource types.
|
||||
## General Principles
|
||||
|
||||
- A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
|
||||
- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
|
||||
- When no resource type exists for a service, still take its connection as one resource-typed parameter, of a type holding the connection fields (base URL, account identifiers, credentials), its secret in a variable the resource references. A plain string parameter or a variable read inside the code only when the user asks for it: the resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose the resource type and ask before creating it
|
||||
- Libraries are installed automatically - do not show installation instructions
|
||||
- In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it `main` (`Main` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no `main`: their language section shows how they take arguments
|
||||
- Where the language has a Windmill client (`wmill`), use it to interact with the platform
|
||||
|
||||
@@ -53,7 +53,7 @@ Use `wmill resource-type list --schema` to discover available resource types.
|
||||
## General Principles
|
||||
|
||||
- A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
|
||||
- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
|
||||
- When no resource type exists for a service, still take its connection as one resource-typed parameter, of a type holding the connection fields (base URL, account identifiers, credentials), its secret in a variable the resource references. A plain string parameter or a variable read inside the code only when the user asks for it: the resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose the resource type and ask before creating it
|
||||
- Libraries are installed automatically - do not show installation instructions
|
||||
- In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it `main` (`Main` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no `main`: their language section shows how they take arguments
|
||||
- Where the language has a Windmill client (`wmill`), use it to interact with the platform
|
||||
|
||||
@@ -53,7 +53,7 @@ Use `wmill resource-type list --schema` to discover available resource types.
|
||||
## General Principles
|
||||
|
||||
- A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
|
||||
- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
|
||||
- When no resource type exists for a service, still take its connection as one resource-typed parameter, of a type holding the connection fields (base URL, account identifiers, credentials), its secret in a variable the resource references. A plain string parameter or a variable read inside the code only when the user asks for it: the resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose the resource type and ask before creating it
|
||||
- Libraries are installed automatically - do not show installation instructions
|
||||
- In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it `main` (`Main` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no `main`: their language section shows how they take arguments
|
||||
- Where the language has a Windmill client (`wmill`), use it to interact with the platform
|
||||
|
||||
@@ -53,7 +53,7 @@ Use `wmill resource-type list --schema` to discover available resource types.
|
||||
## General Principles
|
||||
|
||||
- A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
|
||||
- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
|
||||
- When no resource type exists for a service, still take its connection as one resource-typed parameter, of a type holding the connection fields (base URL, account identifiers, credentials), its secret in a variable the resource references. A plain string parameter or a variable read inside the code only when the user asks for it: the resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose the resource type and ask before creating it
|
||||
- Libraries are installed automatically - do not show installation instructions
|
||||
- In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it `main` (`Main` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no `main`: their language section shows how they take arguments
|
||||
- Where the language has a Windmill client (`wmill`), use it to interact with the platform
|
||||
|
||||
@@ -53,7 +53,7 @@ Use `wmill resource-type list --schema` to discover available resource types.
|
||||
## General Principles
|
||||
|
||||
- A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
|
||||
- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
|
||||
- When no resource type exists for a service, still take its connection as one resource-typed parameter, of a type holding the connection fields (base URL, account identifiers, credentials), its secret in a variable the resource references. A plain string parameter or a variable read inside the code only when the user asks for it: the resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose the resource type and ask before creating it
|
||||
- Libraries are installed automatically - do not show installation instructions
|
||||
- In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it `main` (`Main` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no `main`: their language section shows how they take arguments
|
||||
- Where the language has a Windmill client (`wmill`), use it to interact with the platform
|
||||
|
||||
@@ -53,7 +53,7 @@ Use `wmill resource-type list --schema` to discover available resource types.
|
||||
## General Principles
|
||||
|
||||
- A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
|
||||
- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
|
||||
- When no resource type exists for a service, still take its connection as one resource-typed parameter, of a type holding the connection fields (base URL, account identifiers, credentials), its secret in a variable the resource references. A plain string parameter or a variable read inside the code only when the user asks for it: the resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose the resource type and ask before creating it
|
||||
- Libraries are installed automatically - do not show installation instructions
|
||||
- In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it `main` (`Main` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no `main`: their language section shows how they take arguments
|
||||
- Where the language has a Windmill client (`wmill`), use it to interact with the platform
|
||||
|
||||
@@ -53,7 +53,7 @@ Use `wmill resource-type list --schema` to discover available resource types.
|
||||
## General Principles
|
||||
|
||||
- A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
|
||||
- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
|
||||
- When no resource type exists for a service, still take its connection as one resource-typed parameter, of a type holding the connection fields (base URL, account identifiers, credentials), its secret in a variable the resource references. A plain string parameter or a variable read inside the code only when the user asks for it: the resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose the resource type and ask before creating it
|
||||
- Libraries are installed automatically - do not show installation instructions
|
||||
- In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it `main` (`Main` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no `main`: their language section shows how they take arguments
|
||||
- Where the language has a Windmill client (`wmill`), use it to interact with the platform
|
||||
|
||||
@@ -53,7 +53,7 @@ Use `wmill resource-type list --schema` to discover available resource types.
|
||||
## General Principles
|
||||
|
||||
- A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
|
||||
- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
|
||||
- When no resource type exists for a service, still take its connection as one resource-typed parameter, of a type holding the connection fields (base URL, account identifiers, credentials), its secret in a variable the resource references. A plain string parameter or a variable read inside the code only when the user asks for it: the resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose the resource type and ask before creating it
|
||||
- Libraries are installed automatically - do not show installation instructions
|
||||
- In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it `main` (`Main` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no `main`: their language section shows how they take arguments
|
||||
- Where the language has a Windmill client (`wmill`), use it to interact with the platform
|
||||
|
||||
@@ -53,7 +53,7 @@ Use `wmill resource-type list --schema` to discover available resource types.
|
||||
## General Principles
|
||||
|
||||
- A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
|
||||
- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
|
||||
- When no resource type exists for a service, still take its connection as one resource-typed parameter, of a type holding the connection fields (base URL, account identifiers, credentials), its secret in a variable the resource references. A plain string parameter or a variable read inside the code only when the user asks for it: the resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose the resource type and ask before creating it
|
||||
- Libraries are installed automatically - do not show installation instructions
|
||||
- In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it `main` (`Main` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no `main`: their language section shows how they take arguments
|
||||
- Where the language has a Windmill client (`wmill`), use it to interact with the platform
|
||||
|
||||
@@ -53,7 +53,7 @@ Use `wmill resource-type list --schema` to discover available resource types.
|
||||
## General Principles
|
||||
|
||||
- A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
|
||||
- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
|
||||
- When no resource type exists for a service, still take its connection as one resource-typed parameter, of a type holding the connection fields (base URL, account identifiers, credentials), its secret in a variable the resource references. A plain string parameter or a variable read inside the code only when the user asks for it: the resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose the resource type and ask before creating it
|
||||
- Libraries are installed automatically - do not show installation instructions
|
||||
- In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it `main` (`Main` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no `main`: their language section shows how they take arguments
|
||||
- Where the language has a Windmill client (`wmill`), use it to interact with the platform
|
||||
|
||||
@@ -53,7 +53,7 @@ Use `wmill resource-type list --schema` to discover available resource types.
|
||||
## General Principles
|
||||
|
||||
- A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
|
||||
- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
|
||||
- When no resource type exists for a service, still take its connection as one resource-typed parameter, of a type holding the connection fields (base URL, account identifiers, credentials), its secret in a variable the resource references. A plain string parameter or a variable read inside the code only when the user asks for it: the resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose the resource type and ask before creating it
|
||||
- Libraries are installed automatically - do not show installation instructions
|
||||
- In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it `main` (`Main` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no `main`: their language section shows how they take arguments
|
||||
- Where the language has a Windmill client (`wmill`), use it to interact with the platform
|
||||
|
||||
@@ -53,7 +53,7 @@ Use `wmill resource-type list --schema` to discover available resource types.
|
||||
## General Principles
|
||||
|
||||
- A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
|
||||
- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
|
||||
- When no resource type exists for a service, still take its connection as one resource-typed parameter, of a type holding the connection fields (base URL, account identifiers, credentials), its secret in a variable the resource references. A plain string parameter or a variable read inside the code only when the user asks for it: the resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose the resource type and ask before creating it
|
||||
- Libraries are installed automatically - do not show installation instructions
|
||||
- In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it `main` (`Main` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no `main`: their language section shows how they take arguments
|
||||
- Where the language has a Windmill client (`wmill`), use it to interact with the platform
|
||||
|
||||
@@ -53,7 +53,7 @@ Use `wmill resource-type list --schema` to discover available resource types.
|
||||
## General Principles
|
||||
|
||||
- A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
|
||||
- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
|
||||
- When no resource type exists for a service, still take its connection as one resource-typed parameter, of a type holding the connection fields (base URL, account identifiers, credentials), its secret in a variable the resource references. A plain string parameter or a variable read inside the code only when the user asks for it: the resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose the resource type and ask before creating it
|
||||
- Libraries are installed automatically - do not show installation instructions
|
||||
- In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it `main` (`Main` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no `main`: their language section shows how they take arguments
|
||||
- Where the language has a Windmill client (`wmill`), use it to interact with the platform
|
||||
|
||||
@@ -53,7 +53,7 @@ Use `wmill resource-type list --schema` to discover available resource types.
|
||||
## General Principles
|
||||
|
||||
- A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
|
||||
- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
|
||||
- When no resource type exists for a service, still take its connection as one resource-typed parameter, of a type holding the connection fields (base URL, account identifiers, credentials), its secret in a variable the resource references. A plain string parameter or a variable read inside the code only when the user asks for it: the resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose the resource type and ask before creating it
|
||||
- Libraries are installed automatically - do not show installation instructions
|
||||
- In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it `main` (`Main` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no `main`: their language section shows how they take arguments
|
||||
- Where the language has a Windmill client (`wmill`), use it to interact with the platform
|
||||
|
||||
@@ -53,7 +53,7 @@ Use `wmill resource-type list --schema` to discover available resource types.
|
||||
## General Principles
|
||||
|
||||
- A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
|
||||
- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
|
||||
- When no resource type exists for a service, still take its connection as one resource-typed parameter, of a type holding the connection fields (base URL, account identifiers, credentials), its secret in a variable the resource references. A plain string parameter or a variable read inside the code only when the user asks for it: the resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose the resource type and ask before creating it
|
||||
- Libraries are installed automatically - do not show installation instructions
|
||||
- In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it `main` (`Main` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no `main`: their language section shows how they take arguments
|
||||
- Where the language has a Windmill client (`wmill`), use it to interact with the platform
|
||||
|
||||
@@ -53,7 +53,7 @@ Use `wmill resource-type list --schema` to discover available resource types.
|
||||
## General Principles
|
||||
|
||||
- A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
|
||||
- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
|
||||
- When no resource type exists for a service, still take its connection as one resource-typed parameter, of a type holding the connection fields (base URL, account identifiers, credentials), its secret in a variable the resource references. A plain string parameter or a variable read inside the code only when the user asks for it: the resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose the resource type and ask before creating it
|
||||
- Libraries are installed automatically - do not show installation instructions
|
||||
- In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it `main` (`Main` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no `main`: their language section shows how they take arguments
|
||||
- Where the language has a Windmill client (`wmill`), use it to interact with the platform
|
||||
|
||||
@@ -53,7 +53,7 @@ Use `wmill resource-type list --schema` to discover available resource types.
|
||||
## General Principles
|
||||
|
||||
- A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
|
||||
- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
|
||||
- When no resource type exists for a service, still take its connection as one resource-typed parameter, of a type holding the connection fields (base URL, account identifiers, credentials), its secret in a variable the resource references. A plain string parameter or a variable read inside the code only when the user asks for it: the resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose the resource type and ask before creating it
|
||||
- Libraries are installed automatically - do not show installation instructions
|
||||
- In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it `main` (`Main` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no `main`: their language section shows how they take arguments
|
||||
- Where the language has a Windmill client (`wmill`), use it to interact with the platform
|
||||
|
||||
@@ -53,7 +53,7 @@ Use `wmill resource-type list --schema` to discover available resource types.
|
||||
## General Principles
|
||||
|
||||
- A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
|
||||
- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
|
||||
- When no resource type exists for a service, still take its connection as one resource-typed parameter, of a type holding the connection fields (base URL, account identifiers, credentials), its secret in a variable the resource references. A plain string parameter or a variable read inside the code only when the user asks for it: the resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose the resource type and ask before creating it
|
||||
- Libraries are installed automatically - do not show installation instructions
|
||||
- In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it `main` (`Main` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no `main`: their language section shows how they take arguments
|
||||
- Where the language has a Windmill client (`wmill`), use it to interact with the platform
|
||||
|
||||
@@ -598,6 +598,17 @@ In the flow schema, set the property type to `"object"` with format `"resource-{
|
||||
}
|
||||
```
|
||||
|
||||
### When No Resource Type Fits
|
||||
|
||||
A connection still comes in as one resource input, not as separate string inputs (a URL, a token) or a variable read inside a step: type the input `resource-<name>` with a resource type holding the service's connection fields, its secret in a variable the resource references.
|
||||
|
||||
- If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services.
|
||||
- Otherwise, or when the user prefers it to syncing, propose the resource type and ask before creating it.
|
||||
<!-- chat-only -->
|
||||
- Where you have no way to create a resource type yourself, give the user the schema to add with **Add resource type** on the Resources page.
|
||||
<!-- /chat-only -->
|
||||
- A plain variable is fine when the user asks for it.
|
||||
|
||||
### As Step Input (Static Reference)
|
||||
|
||||
Reference a specific resource using `$res:` prefix:
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
## General Principles
|
||||
|
||||
- A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
|
||||
- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
|
||||
- When no resource type exists for a service, still take its connection as one resource-typed parameter, of a type holding the connection fields (base URL, account identifiers, credentials), its secret in a variable the resource references. A plain string parameter or a variable read inside the code only when the user asks for it: the resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose the resource type and ask before creating it
|
||||
- Libraries are installed automatically - do not show installation instructions
|
||||
- In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it `main` (`Main` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no `main`: their language section shows how they take arguments
|
||||
- Where the language has a Windmill client (`wmill`), use it to interact with the platform
|
||||
|
||||
Reference in New Issue
Block a user