I am trying to write a Windmill module for NixOs. It would be really nicer if there were separate independent packages for the different components of this app. I have a been able to build the windmill cli imperatively by following the Dockerfile provided but it still expects something on the database end (Error: Migrating database: while executing migrations: error returned from database: role "admin" does not exist).

It would be very easy to package if the frontend and backend (and if it needs anything else) can be run with cli flags independently.

Please let me know if you need more details.

Bumps @typescript-eslint/parser from 5.30.3 to 5.30.5.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Describe the bug A clear and concise description of what the bug is. after cloned the project I login as admin. and then I create a script. and click run preview

To Reproduce Steps to reproduce the behavior:

1. cloned the project
2. run docker volume create caddy_data && docker-compose up
3. go to ui, login as admin
4. create a script, and run preview
5. check the log window

Expected behavior A clear and concise description of what you expected to happen. the script is expected to run successfully

Screenshots If applicable, add screenshots to help explain your problem.

Additional context Add any other context about the problem here.

Describe the bug

Note: I'm running this on rootless podman (not docker). Initial tests with demo scripts have worked, but once I try to manipulate the script a bit, I'm running into issues. Not enough information to debug in the logs that I can see.

2022-10-05T20:52:10.880722Z  INFO windmill::worker: fetched job 0183a9eb-8f74-1b4b-15cf-016f0f4b79a1 worker=dt-worker-4CDDY-TVm6M id=0183a9eb-8f74-1b4b-15cf-016f0f4b79a1
2022-10-05T20:52:10.880808Z  INFO windmill::worker: handling job 0183a9eb-8f74-1b4b-15cf-016f0f4b79a1 worker=dt-worker-4CDDY-TVm6M job_id=0183a9eb-8f74-1b4b-15cf-016f0f4b79a1 workspace_id=homelab
2022-10-05T20:52:10.881234Z  INFO windmill::worker: started Go job 0183a9eb-8f74-1b4b-15cf-016f0f4b79a1 worker_name=dt-worker-4CDDY-TVm6M job_id=0183a9eb-8f74-1b4b-15cf-016f0f4b79a1 workspace_id=homelab is_ok=false
2022-10-05T20:52:10.951254Z  INFO windmill::worker: go mod error

To reproduce

1. Create a go script
2. Modify the script to look like below

import (
	"fmt"
	// "rsc.io/quote"
)

func main(user string) (string, error) {
  // fmt.Println(quote.Opt())
  return fmt.Sprintf("Hello, %s!", user), nil
}

4. Hit test
5. See error

job 0183a9eb-8f74-1b4b-15cf-016f0f4b79a1 on worker dt-worker-4CDDY-TVm6M


--- GO DEPENDENCIES SETUP---

go: creating new go.mod: module mymod
go: to add module requirements and sums:
	go mod tidy
Lock file generation failed. Status: Err(ExecutionErr("job process killed"))

Expected behavior

It should run (and then subsequently deploy). I can seemingly add some other imports (e.g. strings seems to import without a problem).

Screenshots

No response

Browser information

No response

Application version

v1.36.0-40-gc8c0daf

Additional Context

Using the container image at :main --> ghcr.io/windmill-labs/windmill@sha256:dfef65413a8a17055adef9e4872e1ed821d2c8d0f9c1f5737f810fbc71227f1f

Podman podman version 4.2.1

In order to easily add new OAuth providers without needing to edit the source, it would be useful if windmill checked if oauth_login.json and oauth_connect.json were present in the local directory first, and use the included src version if they do not exist.

Certain OAuth provides (such as AzureAD) require the authorisation and token endpoints to be specific for the tenant, so a generic URL will not be suitable for them.

This seems like the simplest way currently of enabling adding new OAuth endpoints at the moment since the checks can be added to https://github.com/windmill-labs/windmill/blob/5cbc87e025643941f3853d2fb1b25d292b384c72/backend/windmill-api/src/oauth2.rs#L104 where the check for oauth.json already exists

Describe the bug

The endpoint POST https://app.windmill.dev/api/schedules/preview cannot deal with {"schedule":"0 */0 * * * *","offset":-120}.

To Reproduce

1. Create a schedule
2. While editing the CRON expression, you may temporarily enter 0 */0 * * * *
3. See an error
4. In the network inspector, you'll find an HTTP 502 Bad Gateway from Cloudflare.

Expected behavior

Windmill version Latest on app.windmill.dev as of 2022-09-16.

Additional notes

The following strings cause the same error:

• 0 /0 * * * *
• 0 0 /0
• 0/0 */1 * * *

@sqwishy

This is because

                    "
                  SELECT result
                    FROM completed_job
                   WHERE id = ANY($1)
                     AND workspace_id = $2
                     AND success = true
                    ",
                )
                .bind(jobs.as_slice())
                .bind(w_id)
                .fetch(db)
                .map_ok(|(v,)| v)
                .try_collect::<Vec<serde_json::Value>>()
                .await?;

Does not follow necessarily the order of jobs. Thoughts on how to fix ? Maybe returning the id as well and then aligning the order of jobs id and the resulting vec ids ?

Runs multiple deno workers to fill up the work queue. Scrapes metrics endpoint periodically & exports metrics to influxdb for easy analysis.

I've had little success in actually getting windmill to max out any cores, but I've verified that the queue is actually filling up, so I'm confident this works. New metrics added to windmill are automatically picked up (including labels).

Clicking or targeting the toggle button with the Tab key will open the popup. Tab targeting inside the opened window is disabled, keyboard navigation is only available with the arrow keys, so the user doesn't have to tab through the list of actions if they want to target the next element.

Describe the bug

HTTP 500 and mysterious error in the webapp when creating a schedule with a long name.

Internal: Could not insert into queue 0182b0f2-b7cd-1448-c7b3-8f4f1dd1a991: error returned from database: value too long for type character varying(50)

To Reproduce

1. Go to https://app.windmill.dev/schedule/add
2. Create a name that's longer than 50 characters including /u/your_username/
3. Click on "Schedule"

Expected behavior

• The length isn't restricted at 50 but at 200 or some other length which I'm unlikely to hit.
• The form knows about the limit and does client-side validation.
• The server returns a nice HTTP 400 with the info that the path (UI needs to translate this to the name field) is too long.
  • URL: POST https://app.windmill.dev/api/w/j94_test/schedules/create

Screenshots

Windmill version

v1.31.0-19-g918f6db

Windmill version

Additional context

There were a couple issues with the current implementation:

1. When reading stdout and stderr from the child, as soon as we hit EOF on one we would stop reading from both (line 1420). This could lead to the return value not being read from the job program.

2. Lines read from stdout and stderr are put into a channel and read elsewhere with rx.recv() (line 1497) but that channel isn't read until empty. It is only read in the while !done.load(...) (line 1449) loop and that loop can stop after any .store(true, ...). Which happens when the child exits, when the job is cancelled, when either stdout or stderr reach EOF...

   This can be verified by putting dbg!(rx.recv().await) or a similar assertion after the while loop before returning from that function. It shows the channel still containing log lines on rare occasions.

I was pretty careful in this to maintain the current behaviour; adding comments to express intention.

One difference in this is that some regular intervals (cancel check and ping update) should be more regular?

Before...

at 00ms wait for 10ms at 10ms do things for 3ms at 13ms wait again for 10ms at 23ms do things again ...

With change...

at 00ms wait for 10ms at 10ms do things for 3ms at 13ms wait again but for 7ms at 20ms do things again ...

Which I'm guessing is preferable but I could be wrong.

Fix various bugs:

• resizing any input make it take a single unit of height and impossible to resize
• when creating a new button app, the label says "Default Label" instead of the "Lorem Ipsum" that is default set as its label
• there is some minimum padding between elements. We should make it 1 or 2 px vertically. Otherwise there is no way to actually use text as a label on tops of items such as table/inputs
• User input as a runnable input does not retrigger the compute - We should probably remove the visible toggle altogether, it's confusing - static = invisible - connected = invisible - user input = visible I think we should actually just have Static & Connected, and a toggle in Static that allow for User Input

:robot: I have created a release beep boop

1.57.0 (2022-12-28)

Features

• app: Use consistent styles on settings pages (#1048) (681e2e8)
• backend: resume from owner directly in flow status viewer (#1042) (40195d4)
• frontend: Fix initial component dimensions + Select select + add spinner when buttons are clicked (#1044) (70e7a5d)
• frontend: Properly support resource (#1039) (65f4e86)

This PR was generated with Release Please. See documentation.

Bumps monaco-editor from 0.33.0 to 0.34.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Describe the bug

The "Show code" button only works if one selected a Script. It does not work for a Flow.

To reproduce

1. Go to New Schedule or open the page of an existing Flow
2. Click on "Flow" to have a flow to be triggered by the schedule.
3. Select any flow.
4. Click on "Show code".
5. See error

Expected behavior

It should have looked for a flow with that path, not a script.

Screenshots

Browser information

No response

Application version

Windmill v1.55.0-53-g398c109a

Additional Context

No response

Bumps svelte-preprocess from 4.10.7 to 5.0.0.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps @fortawesome/free-brands-svg-icons from 6.2.0 to 6.2.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.