| Files | Last commit | Last update |
|---|---|---|
fix(release): ship launchable openwork-server and AUR binaries (#4554) * fix(release): ship launchable openwork-server and AUR binaries npm i -g openwork-server installed a binary the shim could not start: the compiled dist/bin/openwork-server left the build job through an artifact upload that drops file modes, so the published tarball carried it as 0644 and the shim failed with EACCES on every run. The publish job now restores the executable bits after downloading the artifact and fails if the binary is still not executable. The AUR package linked /usr/bin/openwork to /opt/openwork/@openworkdesktop, a path the Linux bundle never contained (the Electron executable is /opt/openwork/openwork), so the desktop entry and the openwork command did nothing after install and again after every upgrade. The link now targets the real executable, the package build fails if that file is missing, and the AUR validation workflow fails when /usr/bin/openwork does not resolve to an executable instead of silently falling through to other candidates. * fix(release): verify packed launchers before publication | 1 month ago | |
fix(helm): run the Gateway usage rollup hourly like production (#5922) The chart's retention CronJob ran nightly with the Gateway's default 1,000-row batch, which keeps up with only ~48k requests per day. Hosted production runs it at 5 past every hour with 48 buckets x 5,000 rows. - values: schedule "5 * * * *", new maxBucketsPerRun (48) and maxSourceRowsPerBucket (5000) settings, validated against the Gateway's bounds; reused values without them fall back to defaults. - CronJob: sends the batch body, 600s timeout (900s deadline), logs the count-only summary so operators can alert on backlog. - Gateway: a bodyless call now defaults to 5,000 rows per bucket. - Docs: rollup sizing and non-Helm callers in the Gateway guide and chart README; one "Scheduled maintenance jobs" section covering the rollup and the audit usage refresh for every deploy path. | 24 days ago | |
feat(connectors): refine custom setup behind one rollout flag (#6700) * feat(connectors): show live server and sign-in discovery checks * feat(connectors): consolidate revised setup and review fixes behind one flag * test(connectors): use JSX for discovery checklist rendering * fix(connectors): declare web validation dependency and satisfy UI guardrails * fix(packaging): include connector validation dependency in Den web image * fix(connectors): declare production types for manual OAuth export | 8 days ago | |
feat(ai-gateway): add custom OpenAI-compatible providers (#7087) Admins add a provider by name, OpenAI-compatible base URL and one API key. Den fetches {url}/models, maps OpenRouter-style or plain OpenAI lists to models.dev-shaped model settings (matching the models.dev openrouter catalog), lets the admin pick, template or hand-configure models, tests one through AI Gateway and saves. Saved providers can be renamed, re-pointed, re-keyed, re-fetched and edited. - types: shared contract in @openwork/types/den/gateway-custom-providers - den-api: discover, test, create and edit routes behind gatewayCustomProviders; custom providers keep their own catalog (settings.custom) and one org api_key - gateway: tests and forwards to settings.upstreamBaseUrl (public HTTPS or operator-allowlisted only), prices from saved model cost - den-web: four-step wizard and manage screen; the Another provider row opens the wizard when the flag is on - evals: gateway-custom-provider proof | 1 day ago |