@Craig you can use resource-string instead of resource
@Craig you can use resource-string instead of resource
Rand then fetch the resource in your script
Ryou still see the resource picker
Rbut you're passed the path instead of the value
Rbut can do a branchall with branches having a branchone
RHi @abeeshake456 , for 1) you would want git sync which is ee/cloud only. For 2 you would want to preinstall binaries
R@Ask Inkeep how does one preinstall binaries
R@Ask Inkeep what is git sync
R@Christos have you tried with bun, it should work with bun
RAlso we have a nodejs/npm compatibility mode for EE/cloud
RAlso it should work with python for sure
R@Pedro I will investigate
R@Pedro it's fixed on latest which is building
Rit seems we removed that resource path format, will look into it later
DIf someone encounters as similar problem with a managed Postgres, the following helped us to fix the problem https://github.com/windmill-labs/windmill/issues/2345 We had that fixed differently and some of the more recent updates, crashed the whole system because the suiting rights were missing.
GitHub
Context Azure's hosted PostgreSQL database offering ("Azure database for flexible servers") notoriously does not provide a true superuser account at all, and therefore it is impossibl...
RIt's documented lightly here:https://www.windmill.dev/docs/advanced/self_host#use-an-external-database @DevOpsDan
Self-host Windmill on your own infrastructure.
Rand if you want this to be maintained forever, we have custom migrations on EE with MIGRATION_NO_BYPASSRLS=true
Zany updates on being able to remote a custom workspace error handler if you are not in EE but still have a script selected
Rstandard clause of our contracts is that you will get a perpetual license in the event of cease of operation. But also, we would just OSS everything.
Rupdate workspace_settings set error_handler = nullZsorry, where should I be running that
Ryour windmill db, psql client or as a postgres script that point to your database url
Zgotcha, thanks
R@mattkushner just a note that because of a recursive loop on your imports, it caused stackoverflow on our workers, it's fixed now
Rdeploying soon
AI wonder if I've misunderstood the permission system completely, I have a script that is being executed by
service_user. The service_user only has access to two folders. The script being executed imports from resourcesservice_user runs it the script fails with a Python import error where the script is apparently unable to import the module from the resourcesservice_user recursive accesss to all the dependencies of the script too?Ryes
Rthat''s why it makes more sense to group things into folders and assign permissions at the folder level
Rwould also recommend just using webhook-specific token tied to your users
ASo after some discussion internally we decided to go with service users so we didn't need one token per script that was going to be called. But instead of adding the service user to a group and then granting permissions for the group I just granted permission to the user directly.
And TBH, it's kinda baffling that the permissions work differently when granted on a folder level vs the user level? Maybe I'm missing something, but to me a group just seems like a convenient way to grant the same permissions to a bunch of users?
And TBH, it's kinda baffling that the permissions work differently when granted on a folder level vs the user level? Maybe I'm missing something, but to me a group just seems like a convenient way to grant the same permissions to a bunch of users?
Rthey don't work differently
Rpermissions granted at the folder level are inherited by everything inside it, in a cumulative way with item specific permissions
Rbut maybe you mistyped group instead of folders ?
RBut if that's the case, they also don't work differently
AYeah sorry I meant group. If group and direct assignment should work the same way I must have made some mistake in my assignments, I'll go double-check that then before pointing more fingers