You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit dea6278
Browse filesBrowse the repository at this point in the historyBrowse files
v0.9.53: saved credentials with keyless AWS and Databricks OIDC, read-only API keys, workspace members endpoint, trigger health and pinned versions, proxy support, search source permissions
A service-account-only picker (a saved token or key credential) instead sets
141
+
`credentialKind: 'service-account'` and `mode: 'basic'` (no scopes), and pairs with an advanced
142
+
twin; `isSavedCredentialPicker` matches only this shape:
143
+
```typescript
144
+
{
145
+
id: 'credential',
146
+
title: '{Service} Account',
147
+
type: 'oauth-input',
148
+
serviceId: '{service}',
149
+
credentialKind: 'service-account',
150
+
canonicalParamId: 'oauthCredential',
151
+
mode: 'basic',
152
+
placeholder: 'Select {Service} credential',
153
+
required: true,
154
+
},
155
+
{
156
+
id: 'manualCredential',
157
+
title: '{Service} Account',
158
+
type: 'short-input',
159
+
canonicalParamId: 'oauthCredential',
160
+
mode: 'advanced',
161
+
placeholder: 'Enter credential ID',
162
+
required: true,
163
+
}
164
+
```
165
+
139
166
**Scopes:** Always use `getScopesForService(serviceId)` from `@/lib/oauth/utils` for `requiredScopes`. Never hardcode scope arrays — the single source of truth is `OAUTH_PROVIDERS` in `lib/oauth/oauth.ts`.
140
167
141
168
**Scope descriptions:** When adding a new OAuth provider, also add human-readable descriptions for all scopes in `SCOPE_DESCRIPTIONS` within `lib/oauth/utils.ts`.
Optional companions: `credentialLabels` (override the picker's section/connect-row copy) and `allowServiceAccounts: true` (trigger-mode only — list service accounts, which triggers otherwise exclude; set only when the trigger's polling path can resolve a service-account token). The connect modal, provider families (Google JSON key, Atlassian token, token-paste, client-credential, Slack bot), and the preview gate are all resolved from `serviceAccountProviderId` — you don't wire them per block.
161
188
189
+
### Credential-only successor (replacing inline secrets)
190
+
191
+
A block that takes a secret inline keeps running for existing workflows; the saved-credential
192
+
version is a new block type that spreads it. Keep the successor an object literal with the picker
193
+
written inline, because the docs generator reads the source text:
194
+
195
+
```typescript
196
+
exportconst ServiceV2Block:BlockConfig= {
197
+
...ServiceBlock,
198
+
type: 'service_v2',
199
+
authMode: AuthMode.OAuth,
200
+
hideFromToolbar: false,
201
+
sunset: undefined,
202
+
...withSavedCredential(ServiceBlock, {
203
+
id: 'credential',
204
+
type: 'oauth-input',
205
+
serviceId: 'service',
206
+
title: 'Service Credential',
207
+
}),
208
+
}
209
+
```
210
+
211
+
- The legacy block changes only by `hideFromToolbar: true` and `sunset: { status: 'legacy',
212
+
replacedBy: 'service_v2' }` (an older `_v2` points at the new `_v3`). Register both types.
213
+
-`withSavedCredential` (`blocks/utils.ts`) swaps exactly the fields its policy in
214
+
`SAVED_CREDENTIAL_OAUTH` supplies for the picker, places it directly under the operation
215
+
dropdown, inherits the replaced fields' `condition` and `required`, and leaves trigger-mode
216
+
fields alone. Pass `required` when the replaced fields disagree (an optional host), and `params`
217
+
only when the legacy params builder validates the secret: extract that builder so the legacy
218
+
block calls it unchanged (`blocks/legacy-builders.test.ts`) and the successor skips the check.
219
+
- Add the pair to `serializer/saved-credentials.test.ts` (`optionalIds` for replaced fields the
220
+
legacy block never required), and grep for code that hard-codes the legacy type (`getBlock`,
221
+
`integration.type ===`, availability lookups), which now resolves to the successor.
222
+
162
223
### OAuth deployment availability (required for integration blocks)
163
224
164
225
A visible tools-category block with OAuth is deployment-gated. Its `oauth-input.serviceId` is
@@ -661,7 +722,8 @@ outputs: {
661
722
When creating V2 blocks (alongside legacy V1):
662
723
663
724
```typescript
664
-
// V1 Block - mark as legacy
725
+
// V1 Block - mark as legacy. A credential-only successor is the exception: the
726
+
// successor keeps the legacy block's name, so neither block is renamed.
Copy file name to clipboardExpand all lines: .agents/skills/add-integration/SKILL.md
+52-1Lines changed: 52 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -43,6 +43,12 @@ supported paths and choose the simplest supported setup for the intended user:
43
43
| Customer-owned client credentials | Saved `service_account` credential with a client ID and secret | Internal-app eligibility, grant activation, scope syntax, token lifetime and revocation behavior |
44
44
| API token or personal access token | Saved token service account when reusable connections are useful | Token permissions, identity verification, expiry and rotation |
| Cloud workload identity (AWS role, Databricks/Snowflake/Entra/GCP federation) | Keyless saved credential: Sim signs a short-lived OIDC token the customer's cloud trusts. Add the provider to every table in `lib/credentials/workload-identity/audiences.ts` (`WORKLOAD_IDENTITY_PROVIDERS`, its service-account provider ID map, `WORKLOAD_IDENTITY_KEYLESS_CONFIGS`, `WORKLOAD_IDENTITY_AUDIENCES`) and to `MIXED_MODE_PROVIDERS` in `lib/credentials/application/prepare-workload-identity.ts`| Issuer and audience the provider accepts, how the trust pins the subject, token lifetime |
47
+
48
+
API, CLI, and MCP callers set up keyless in two steps: `POST /api/v2/credentials/workload-identity/subjects`
49
+
(or `sim credentials keyless-subject <providerId> --output json`) returns the subject to trust and a
50
+
`keylessConfig`; they add its `requiredConfigFields` and create the credential with it. The provider
51
+
catalog advertises `keyless` only when the deployment can sign tokens.
46
52
47
53
Do not present customer-owned credentials as a way around a provider's approval requirements
48
54
for a shared public integration. Explain the supported account/app type in the setup docs. Keep
@@ -66,6 +72,50 @@ Use explicit permission choices when the supported operations have different acc
66
72
region and permission selections on reconnect unless the user changes them. Verify documented
67
73
identity endpoints rather than guessing which person a client-credentials token represents.
Copy file name to clipboardExpand all lines: .agents/skills/validate-integration/SKILL.md
+18Lines changed: 18 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -218,6 +218,24 @@ For **each tool** in `tools.access`:
218
218
- True/false → `switch` (a Yes/No `dropdown` only when the tool needs a third "unset" state)
219
219
- Credentials → `oauth-input` with correct `serviceId`
220
220
- Every tool with a `credential`/`oauthCredential` param declares `oauth: { required: true, provider }` matching that `serviceId`, plus `credentialKind: 'service-account'` when only service accounts are supported
221
+
-[ ] In a new block or credential-only successor, a pasted key, token, or token + host comes from a
222
+
saved token credential (add-integration → Token credentials), not an inline `password` field
223
+
(legacy blocks keep theirs); a successor changes its legacy block only by `hideFromToolbar`
224
+
and `sunset`, and its picker sits under the operation
225
+
-[ ] For a token-credential integration, every tool in `tools.access` declares the service's
226
+
`tokenCredentialOAuth` policy, every
227
+
param that decides the request host is mapped, and the stored domain is in the form the tools
228
+
build URLs from (`check-block-registry.ts origin/staging` passes)
Copy file name to clipboardExpand all lines: .github/CI.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,13 +4,13 @@ The `changes` job runs Turborepo 2.9.14's `affectedTasks` query before installin
4
4
5
5
A PR compares the checked-out GitHub merge commit with its first parent: the actual target revision tested by that merge. The PR event's base SHA can become stale when the target advances. Scoping requires a matching GitHub merge ref and SHA, exactly two merge parents, and a usable target parent; otherwise every check runs. This works with the existing depth-two checkout without fetching older ancestry. Main/staging pushes execute all checks; the parent `ci` workflow skips checks on `dev` pushes, while PRs targeting `dev` still run checks. A manual `checks` run executes all checks unless supplied a full base commit SHA to reproduce a scoped plan. Missing history, an empty diff, unknown files outside the workspace graph, root script/CI changes, or a planner error run every check. Missing selection outputs fail the aggregate gate. The gate also rejects an omitted dependency, any failed/cancelled job, and any skip that its explicit selection flag did not authorize.
6
6
7
-
Dedicated docs verification uses the same planner, comparing pushes with their previous commit and PRs with the tested merge's first parent. Site acceptance follows `docs#build` and its transitive package dependencies. The app's docs-consumer task depends on server runtime and that docs build: backend-only changes run the platform consumer against the docs app, while site changes also run corpus and browser checks. Independent SDK and unit-only edits skip those production jobs. The required `docs HTTP` gate verifies explicit site/platform selections before accepting any skip.
7
+
Dedicated docs verification uses the same planner, comparing pushes with their previous commit and PRs with the tested merge's first parent. Site acceptance follows `docs#build` and its transitive package dependencies. The app's docs-consumer task depends on server runtime and that docs build: backend-only changes run the platform consumer against the docs app, while site changes also run corpus and browser checks. Standalone package and unit-only edits skip those production jobs. The required `docs HTTP` gate verifies explicit site/platform selections before accepting any skip.
8
8
9
9
Docs production builds run once and publish an artifact to isolated HTTP, corpus, Chromium, and WebKit jobs. Source checks keep their own checkout because generator verification mutates inputs. Content caches use separate lint/source/build namespaces; generation validates every restore, repairs missing declarations, and removes obsolete modules. The Next build cache keeps its supported incremental behavior. Content and Next caches have size limits, and Next cache files expire after seven days; successful content eviction happens after all consumers finish.
10
10
11
11
| Change | Expensive checks selected |
12
12
| --- | --- |
13
-
|Independent SDK| That workspace's tests and type-check; no app build, services, or browsers |
13
+
|Standalone package| That workspace's tests and type-check; no app build, services, or browsers |
14
14
| App unit test | App test shards and test type check |
15
15
| Integration test | Both provision paths; no HTTP/browser job merely for the test edit |
16
16
| Workspace UI | Database integration, mobile, SEO and live Electron, plus app tests/build |
Copy file name to clipboardExpand all lines: .github/CONTRIBUTING.md
+5-9Lines changed: 5 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -140,23 +140,19 @@ Using clear and consistent commit messages makes it easier for everyone to under
140
140
141
141
To set up your local development environment:
142
142
143
-
### Option 1: Using NPM Package (Simplest)
143
+
### Option 1: Using the Setup Wizard (Simplest)
144
144
145
-
The easiest way to run Sim locally is using our NPM package:
145
+
The easiest way to run Sim locally is the interactive setup wizard:
146
146
147
147
```bash
148
-
npx simstudio
148
+
npx sim-setup
149
149
```
150
150
151
-
After running this command, open [http://localhost:3000/](http://localhost:3000/) in your browser.
152
-
153
-
#### Options
154
-
155
-
-`-p, --port <port>`: Specify the port to run Sim on (default: 3000)
156
-
-`--no-pull`: Skip pulling the latest Docker images
151
+
When it finishes, open [http://localhost:3000/](http://localhost:3000/) in your browser. Inside a cloned Sim repository, run `bun run sim-setup --mode dev` for the local development mode.
157
152
158
153
#### Requirements
159
154
155
+
- Node.js 20+
160
156
- Docker must be installed and running on your machine
0 commit comments