sledge
sledge
WWindmill
Created by sledge on 11/27/2024 in #help
Worker caching weirdness
One interesting tidbit - the bun requests used http 1.1 - deno used http 2.0
10 replies
WWindmill
Created by sledge on 11/27/2024 in #help
Worker caching weirdness
And I agree - since this is just fetch getting executed by deno - this has to be a caching issue with the KV store.
10 replies
WWindmill
Created by sledge on 11/27/2024 in #help
Worker caching weirdness
Well the response headers look pretty much the same from the deno requests as from curl: Response Headers: access-control-allow-origin: * content-type: text/plain date: Wed, 27 Nov 2024 15:21:36 GMT expires: Fri Dec 27 13:33:55 2024 GMT fly-request-id: 01JDQ3DAFZC30W8XJXY9HJGJ6D-sea kvdb-cache-status: HIT kvdb-edge-region: sjc server: Fly/d42d3a7f1 (2024-11-25) strict-transport-security: max-age=31536000; includeSubDomains; preload vary: Origin via: 2 fly.io x-content-type-options: nosniff x-frame-options: SAMEORIGIN x-response-time: 0.490ms x-xss-protection: 1; mode=block Got 5 messages
10 replies
WWindmill
Created by sledge on 11/27/2024 in #help
Worker caching weirdness
Those headers are from running curl here locally on my machine. I'm gonna see what the response headers look like on the weird responses.
10 replies
WWindmill
Created by sledge on 11/27/2024 in #help
Worker caching weirdness
That is what I thought too ... how could this be a WM issue if they're just launching the script on a worker using the specified runtime.
10 replies
WWindmill
Created by sledge on 11/27/2024 in #help
Worker caching weirdness
I tried both as a normal deno and normal bun.
10 replies
WWindmill
Created by sledge on 11/27/2024 in #help
Worker caching weirdness
Maybe a bug in the response headers from the KV store? HTTP/2 200 server: Fly/d42d3a7f1 (2024-11-25) date: Wed, 27 Nov 2024 15:09:05 GMT content-type: text/plain kvdb-edge-region: iad vary: Accept-Encoding vary: Origin access-control-allow-origin: * expires: Fri Dec 27 14:01:15 2024 GMT strict-transport-security: max-age=31536000; includeSubDomains; preload x-content-type-options: nosniff x-frame-options: SAMEORIGIN x-response-time: 0.467ms x-xss-protection: 1; mode=block kvdb-cache-status: HIT via: 2 fly.io fly-request-id: 01JDQ2PCK6MXMMG9KAP8ZJAQJ2-iad This is what I see from curl.
10 replies
WWindmill
Created by itsupport505 on 8/26/2024 in #help
Has anyone run windmill via coolify?
Yeah - I pulled caddy out of the docker compose file and it ran fine under coolify.
6 replies
WWindmill
Created by sledge on 7/11/2024 in #help
CLI thinks it needs to rename on remote
Ahhh, got it. I made a new local folder, did a wmill init, changed the defaultTs to deno then did a sync and it did properly pull the scripts without .deno. in the filename. Thank you @rubenf .
4 replies
WWindmill
Created by sledge on 7/2/2024 in #help
Generating tokens for apps?
Maybe this should be changed to a feature request - to allow the token label to be displayed on the runs tab instead of or in addition to the user.
2 replies
WWindmill
Created by sledge on 6/18/2024 in #help
Migrating content to another Windmill instance
Therefore, in answer to the question, doing the wmill sync pull --raw and wmill sync push --raw between the two workspaces worked fine and enabled very simple new-server bringup.
8 replies
WWindmill
Created by sledge on 6/18/2024 in #help
Migrating content to another Windmill instance
Ok - problem was my app API URL was configurable and when I dropped in the URL for the new server I forgot to include the /api/w/workspace-name portion and Windmill was returning a different set of CORS headers therefore (for invalid routes). The confusing thing was that the browser dev tools said the server was "Caddy" - so I thought I had a caddy server problem. I suppose it says that because I'm using the Caddy reverse proxy.
8 replies
WWindmill
Created by sledge on 6/18/2024 in #help
Migrating content to another Windmill instance
Yes, seems to have worked. Unfortunately this instance seems to have some other issues. On mine I did not have to do anything with CORS. I'm able to access it without issue by name - on my tailscale network, from my browser app. However, this new instance that my client setup is failing due to CORS issues. So I need to figure that out before I can confirm that the wmill sync pull / push worked.
8 replies
WWindmill
Created by sledge on 6/18/2024 in #help
Migrating content to another Windmill instance
So @rubenf I have a bunch of scripts in my locally running WM instance that I also have synced to a local folder via wmill sync pull and pushed to a git repo (not using windmill git sync). My client now has their instance of WM up and running and I want to migrate all of the scripts. You mention that the cli sync is able to do 99% of that ... do I just need to create a new workspace on the new instance then do a wmill sync push from the git cloned folder after logging into the new workspace with cli?
8 replies
WWindmill
Created by sledge on 6/26/2024 in #help
Staying in sync
Same way - you make your changes in the dev workspace, via UI or local and keep local synced via wmill cli. Once you're ready you git commit + push that local folder to branch in git, PR it, then merge into prod branch which would have a job that would wmill sync it to prod workspace.
18 replies
WWindmill
Created by sledge on 6/26/2024 in #help
Staying in sync
All your work would happen in the dev workspace while your gitlab job would sync push to the prod workspace.
18 replies
WWindmill
Created by sledge on 6/26/2024 in #help
Staying in sync
So you could accomplish the same with a single public-internet-accessible install of windmill by just using two workspaces.
18 replies
WWindmill
Created by sledge on 6/26/2024 in #help
Staying in sync
But if you directly wmill sync push, without doing a git commit + push, then someone else does a git push, your workspace code changes are gone (but still available locally if you have not done a wmill sync pull).
18 replies