this doesn't seem to work if you version lock dependencies

R

rubenf•12/26/23, 3:31 PM

NEW [Minor]

Schedules flows can now be toggled to never overlap over their full execution

NNacki this doesn't seem to work if you version lock dependencies

R

rubenf•12/27/23, 1:29 AM

this is fixed in latest

R

rubenf•1/11/24, 11:59 AM

There are lot of unannounced change (we didn't have time to write proper changelog). But PSA:
the .wmill folder was source of much confusion. It's not needed anymore in a world where Git Sync exist.
wmill sync --raw will soon become the default and it doesn't rely on the .wmill folder
Since not everyone can use Git Sync since it's under EE, the previous behavior will now be flagged under --stateful.
We will keep a transition period for a few weeks and then change the default, update and add --stateful to your wmill commands if you rely on this behavior.

R

rubenf•1/14/24, 6:12 PM

We have an alpha of a NodeJS compatibility mode (a true one, where NodeJS is the actual runtime). We are looking for enterprise beta testers to test it with your legacy NodeJS code.

R

rubenf•1/22/24, 3:02 PM

PSA, we are deprecating .wmillignore in favor of a wmill.yaml that has an includes field. It's already the case in 1.250.0 of the CLI (which is back-compatible, nothing has broken). We noticed that it was way more common to have whitelist patterns than blacklist and we will centralize every windmill setting in this wmill.yaml

See example here: https://github.com/windmill-labs/windmill-sync-example/commit/62949af56be1c54a3f9e6364663d93e71c1cab73#diff-cb4c7b506a5f402c[…]6d342bb74b338806fb402

Lots of very exciting changes coming to the CLI for a great fully local development experience. More to share soon

GitHub

update to 1.250.0 · windmill-labs/windmill-sync-example@62949af

H

henri-c•2/6/24, 5:02 PM

NEW [Major]

We're starting to catch up on our changelogs that haven't been announced yet. The first is the Decision Tree component, which allows you to create TypeForm-like dynamic forms embedding scripts & flows.

Changelog: https://www.windmill.dev/changelog/decision-tree
Tutorial: https://www.windmill.dev/blog/dynamic-form

H

henri-c•2/6/24, 5:04 PM

We're taking this opportunity to announce our new Changelog page, where you can view our major releases as well as the date and version in which they were deployed: https://www.windmill.dev/changelog

H

henri-c•2/12/24, 6:29 PM

NEW [Major]

Rich table display

Released on 23/01/2024 under v1.251.1

Display arrays of objects as interactive tables (search, filter, hide, view, download as csv)

Changelog: https://www.windmill.dev/changelog/rich-render
Docs: https://www.windmill.dev/docs/core_concepts/rich_display_rendering#rich-table-display

Rich Display Rendering | Windmill

The result renderer in Windmill supports rich display rendering, allowing you to customize the display format of your results. By leveraging specific formats, you can display images, files, tables, HTML, JSON, and more.

R

rubenf•2/13/24, 9:41 AM

In latest, we did a few improvements to the runs page which should feel snappier. And on the admins workspace, you can now see the runs of all workspaces at once:

H

henri-c•2/16/24, 4:27 PM

NEW [Major]

Database Studio

Released on 23/01/2024 under v1.251.1

In apps, interaction with database content made easy: from a PostgreSQL or MySQL resource, display, edit, add rows, delete rows ... and connect to other components.

Changelog: https://www.windmill.dev/changelog/database-studio
Docs: https://www.windmill.dev/docs/apps/app_configuration_settings/database_studio

R

rubenf•2/20/24, 11:26 AM

runnable fields can now be individually selected to not trigger recompute

H

Hugo•2/21/24, 6:01 PM

NEW [Major]

Flow & Metadata Copilot

Released on 15/02/2024 under v1.270.0

The Flow & Metadata Copilot is an assistant powered by an OpenAI resource that simplifies your script & flows building experience by population fields (summaries, descriptions, step input expressions) automatically based on context and prompts.

Changelog: https://www.windmill.dev/changelog/ai-copilot
Docs: https://www.windmill.dev/docs/core_concepts/ai_generation#step-input-copilot

R

rubenf•2/26/24, 5:45 PM

I will write a blog post asap on it, but this weekend we achieved a very cool property for a distributed sytem:

Scripts were always 100% reliable as in, they would either execute and be completed with a success or failure, or retried if the worker crashed at ANY point (and I really mean any, even mid transaction, that's the beauty on relying on the beast that is Postgresql). It was achieved using atomic statement for pulling jobs and writing back their progress timestamps, regularly and on completion.
Flows were 99% reliable but had some extremely ephemeral point-in-time where if a crash happened, a flow could be stuck forever. Those events were so rare and unlikely on a modern infra that we didn't prioritize improving that but that is now done:
Flows are now guaranteed to complete when they are scheduled given that enough workers are there to process them. This is done through a series of atomic statements in the right places of the finite state machine that runs the flows. If such crash on the machine happen, the flow will be guaranteed to progress in a finite amount of time and propagate the error back up, and then have it be treated by error handlers if any making windmill 100% observable.

R

rubenf•2/27/24, 12:30 AM

(sadly, I broke some eggs with the change above, if you upgraded in the last 2 days and were using the "No flow overlap" feature of schedules for flows, then your schedules silently turned off). Update to latest release and re-enable those schedules to fix.

R

rubenf•2/27/24, 5:20 PM

Second PSA, if you use parrallel branches/for-loop and there is a time difference of ending branch > 30s, and you updated in the last 3 days, please update to 1.279.0. There is an edge-case that would make your flow being caught and cancelled by the new timeout progress monitor.

R

rubenf•3/6/24, 8:29 PM

We are releasing in beta Workflow as code for Python and Typescript. No more excuse to use Airflow or Prefect: https://www.windmill.dev/docs/core_concepts/workflows_as_code

from wmill import task

import pandas as pd
import numpy as np

# The pin is important since task is a decorator available only from 1.286.2

#extra_requirements:
#wmill>=1.286.2


##You can specify tag to run the task on a specific type of worker
@task(tag="highmem")
def heavy_compute(n: int):
    df = pd.DataFrame(np.random.randn(100, 4), columns=list('ABCD'))
    return df.sum().sum()


@task
def send_result(res: int, email: str):
    # logs of the subtask are available in the main task logs
    print(f"Sending result {res} to {email}")
    return "OK"

def main(n: int):
    l = []

    # to run things in parallel, simply use multiprocessing Pool map instead: https://docs.python.org/3/library/multiprocessing.html
    for i in range(n):
        l.append(heavy_compute(i))
    print(l)
    return send_result(sum(l), "example@example.com")

from wmill import task

import pandas as pd
import numpy as np

# The pin is important since task is a decorator available only from 1.286.2

#extra_requirements:
#wmill>=1.286.2


##You can specify tag to run the task on a specific type of worker
@task(tag="highmem")
def heavy_compute(n: int):
    df = pd.DataFrame(np.random.randn(100, 4), columns=list('ABCD'))
    return df.sum().sum()


@task
def send_result(res: int, email: str):
    # logs of the subtask are available in the main task logs
    print(f"Sending result {res} to {email}")
    return "OK"

def main(n: int):
    l = []

    # to run things in parallel, simply use multiprocessing Pool map instead: https://docs.python.org/3/library/multiprocessing.html
    for i in range(n):
        l.append(heavy_compute(i))
    print(l)
    return send_result(sum(l), "example@example.com")

from wmill import task

import pandas as pd
import numpy as np

# The pin is important since task is a decorator available only from 1.286.2

#extra_requirements:
#wmill>=1.286.2


##You can specify tag to run the task on a specific type of worker
@task(tag="highmem")
def heavy_compute(n: int):
    df = pd.DataFrame(np.random.randn(100, 4), columns=list('ABCD'))
    return df.sum().sum()


@task
def send_result(res: int, email: str):
    # logs of the subtask are available in the main task logs
    print(f"Sending result {res} to {email}")
    return "OK"

def main(n: int):
    l = []

    # to run things in parallel, simply use multiprocessing Pool map instead: https://docs.python.org/3/library/multiprocessing.html
    for i in range(n):
        l.append(heavy_compute(i))
    print(l)
    return send_result(sum(l), "example@example.com")

from wmill import task

import pandas as pd
import numpy as np

# The pin is important since task is a decorator available only from 1.286.2

#extra_requirements:
#wmill>=1.286.2


##You can specify tag to run the task on a specific type of worker
@task(tag="highmem")
def heavy_compute(n: int):
    df = pd.DataFrame(np.random.randn(100, 4), columns=list('ABCD'))
    return df.sum().sum()


@task
def send_result(res: int, email: str):
    # logs of the subtask are available in the main task logs
    print(f"Sending result {res} to {email}")
    return "OK"

def main(n: int):
    l = []

    # to run things in parallel, simply use multiprocessing Pool map instead: https://docs.python.org/3/library/multiprocessing.html
    for i in range(n):
        l.append(heavy_compute(i))
    print(l)
    return send_result(sum(l), "example@example.com")

Workflows as Code | Windmill

Flows are not the only way to write distributed programs that execute distinct jobs. Another approach is to write a program that defines the jobs and their dependencies, and then execute that program. This is known as workflows as code.

R

rubenf•3/9/24, 2:25 PM

Bun is now the default language in the UI:

R

rubenf•3/9/24, 4:28 PM

(In not too long, we will make language order and starting templates configurable)

R

rubenf•3/13/24, 8:34 AM

Windmill supports many languages, but organizations usually only use a few, now you can configure the languages that are visible and their orders:
The setting apply to scripts, flows and apps and is global to all users within a workspace but only configurable by admins

R

rubenf•3/23/24, 4:05 PM

All about logs

One of our large scale customers noticed that their database disk usage was much much higher than they anticipated. After investigation, we realized that our use of the database for streaming was very suboptimal in a few ways due to the nature of update in postgres. When you update a row in Postgres, it will actually keep the prior row as a dead tuple until it is collected. It doesn't matter in much case but it will if you're appending a few log lines to a 25MB log row, every 500ms.
We have completely refactored the way we deal with logs in major ways and starting on 1.295.0 you should feel comfortable having extremely large logs on Windmill

First action we took was to extract the logs from the queue table to a separate table. That was to avoid update unrelated to logs creating dead tuples. Second action was to make the streaming rate from the worker adaptive to the the duration of the job: a longer job does not need to update its log every 500ms, every 2.5s is reasonable for jobs of more than 10s, 5s for 60s+, etc...

But that was still not enough, even every 2.5s an update on a 25mb log would create lots of heavy dead tuples. And 25MB is not that large, our customer should feel confident streaming GBs of logs per job with jobs that run for months.

So we completely revisited the way we store logs to only treat the database as a buffer for streaming purpose rather than long term storage. We keep the db as a 5000 char buffer to still provide the same instant preview as before but:

On EE, the logs will be streamed to S3 if you connected your instance to S3, everything is seamless and you can still download the entire log, windmill will take care of streaming from S3
non EE, the excess log (>10000 chars) will be stored on disk of the worker (mount /tmp/windmill/logs to persist those)

Now the db only store at most 5Kb of logs per job rows, reducing the pressure on it by order of magnitudes, while users can now run jobs with unlimited logs with minimal impact on the worker or db. And the logs are still as live as before

R

rubenf•3/23/24, 4:11 PM

Very related update, but our use of the logs in the frontend was also suboptimal, we were loading many of them unecessarily before the user was in a view that actually rendered them, for instance in the flow status viewer, runs page detail and other log views. We now do it just-in-time, as soon as the user need them which will make windmill overall feel more reactive, avoid unecessary network calls, especially in the flow status viewer were the logs of all jobs were fetched even though none were displayed.

R

rubenf•3/23/24, 4:33 PM

Also, we refactored our s3 distributed python cache to not rely on rclone anymore but to be done natively in rust:

Much better and parallelized performance for dependency fetching from distributed cache
less s3 usage as due to the increase in performance, there is no need to sync the cache at start, everything can be done just in time

We also simplified how easy it was to set it up, directly in the instance settings UI so given it's the same cache used by the logs, we now recommend all EE customers to set it up, even at smaller scale.

R

rubenf•3/23/24, 4:35 PM

and last but not least, @Hugo implemented custom contextual variables that will act as env variable for all jobs within a workspace. We still recommend using variables but in some cases (for instance your imports depend on env variables), this might be a good escape hatch.

R

rubenf•3/26/24, 6:44 PM

Introducing custom flow states:
You can now set and retrieve a value given a key from any step of flow and it will be available from within the flow globally. That state will be stored in the flow state itself and thus has the same lifetime than the flow job itself.

import * as wmill from "windmill-client@1.297.0"

export async function main(x: string) {
  await wmill.setFlowUserState("FOO", 42)
  return await wmill.getFlowUserState("FOO")

}

import * as wmill from "windmill-client@1.297.0"

export async function main(x: string) {
  await wmill.setFlowUserState("FOO", 42)
  return await wmill.getFlowUserState("FOO")

}

import * as wmill from "windmill-client@1.297.0"

export async function main(x: string) {
  await wmill.setFlowUserState("FOO", 42)
  return await wmill.getFlowUserState("FOO")

}

import * as wmill from "windmill-client@1.297.0"

export async function main(x: string) {
  await wmill.setFlowUserState("FOO", 42)
  return await wmill.getFlowUserState("FOO")

}

import wmill
#extra_requirements:
#wmill==1.297.0

def main(x: str):
    wmill.set_flow_user_state("foobar", 43)
    return wmill.get_flow_user_state("foobar")

import wmill
#extra_requirements:
#wmill==1.297.0

def main(x: str):
    wmill.set_flow_user_state("foobar", 43)
    return wmill.get_flow_user_state("foobar")

import wmill
#extra_requirements:
#wmill==1.297.0

def main(x: str):
    wmill.set_flow_user_state("foobar", 43)
    return wmill.get_flow_user_state("foobar")

import wmill
#extra_requirements:
#wmill==1.297.0

def main(x: str):
    wmill.set_flow_user_state("foobar", 43)
    return wmill.get_flow_user_state("foobar")

Make it a powerful escape hatch when passing data as output/input is not feasible and using getResource/setResource has the issue of cluttering the workspace and inconvenient UX

R

rubenf•3/26/24, 6:55 PM

also QOL improvements, webhook specific tokens have a default unique label that is displayed as the username in runs make it easy to distinguish when a run is from a user or a webhook:

R

rubenf•3/27/24, 1:17 PM

All about approval steps

you can now remove the deny button from approval page to force more complex patterns using forms with enums processed in ulterior steps
Now approval steps resume forms at any level will be displayed at the top-level, regardless of their depths
We have updated the default template and there is a new field description to add very clear instructions which support the whole range of of rich display rendering
```typescript
import * as wmill from "windmill-client@^1.158.2"

export async function main(approver?: string) {
const urls = await wmill.getResumeUrls(approver)
// send the urls to their intended recipients

// if the resumeUrls are part of the response, they will be available to any persons having access
// to the run page and allowed to be approved from there, even from non owners of the flow
// self-approval is disablable in the suspend options
return {
...urls,
default_args: {},
enums: {},
description: {
render_all: [
{
markdown: "# We have located the secret vault with thousands of H100"
},
{
map: { lat: -30, lon: 10, markers: [{lat: -30, lon: 0, title: "It's here"}]}
},
"Just kidding"
]
}
// supports all formats from rich display rendering such as simple strings,
// but also markdown, html, images, tables, maps, render_all, etc...
// https://www.windmill.dev/docs/core_concepts/rich_display_rendering
}
}
```

R

rubenf•3/27/24, 6:15 PM

we now support GH flavored markdown for description of scripts, flows, resources,

R

rubenf•4/1/24, 7:05 PM

latest windmill is on Bun 1.1 which fixes most of the small issues we've seen (grpc/http2 compatibility, brotli compression) and also faster performances overall: https://bun.sh/blog/bun-v1.1

Bun

Bun 1.1

Bun now supports Windows!

R

rubenf•4/2/24, 8:34 AM

Sometimes, the general error handler of a flow is not practical if you want to process the error directly after the step. We now allow this pattern with the toggle "Continue on error" in the Retries settings (and it doesn't actually require any retries to be set). Which avoids try/catching within the step to return the error and is compatible with retries

R

rubenf•4/2/24, 4:18 PM

New flow primitives: While Loop

They are very similar to For loop except they have no iterator expression so they really expect you to set a step to break out. This is similar to constructs like

loop

loop

loop

loop (Rust), or

while (true)

while (true)

while (true)

while (true)

R

rubenf•4/2/24, 4:19 PM

This can very easily be combined with custom flow user states to iterate over a list whose size cannot be know prior to starting the loop by looping until the last pagination index is undefined

F

Faton•4/16/24, 9:19 AM

We added actions to AgGrid tables ( including the Database Studio).
Simply add a button, a checkbox or select field and add interactivity to your tables.

R

rubenf•4/24/24, 11:19 AM

We have a very cool feature to add dynamic tags to jobs that we will announce in more details soon. However, it creates an index on the completed job table and even though it does it concurrently (so it doesn't actually lock the tables) it can take a while to apply the full migration and it's expected and normal if you have lots of jobs in the completed_job table that your rollout takes a bit of time (up to an hour) for your pods to be ready, they're all waiting on that migration to finish.

R

rubenf•4/26/24, 11:59 AM

Go binaries are now wholly cached by the EE global cache which means running them is a lot faster on kube clusters like the cloud ones

H

henri-c•4/26/24, 12:21 PM

2 pieces of changelog today

AgGrid Infinite Table

New AgGrid component to display an Ag Grid table with infinite scrolling and rows display, and a search function

Changelog: https://www.windmill.dev/changelog/aggrid-infinite-table
Docs: https://www.windmill.dev/docs/apps/app_configuration_settings/aggrid_table#aggrid-infinite-table

H

henri-c•4/26/24, 12:21 PM

Jobs Labels

Labels allow to add static or dynamic tags to jobs with property "wm_labels" followed by an array of strings (one or several labels). You can then filter jobs on labels from Runs menu.

Changelog: https://www.windmill.dev/changelog/jobs-labels
Docs: https://www.windmill.dev/docs/core_concepts/monitor_past_and_future_runs#jobs-labels

R

rubenf•4/28/24, 3:01 PM

Latest CLI and Git Sync have 2 major improvements:

Wherever there is a lockfile (in scripts, flows and apps), the lockfile is now stored in a separate file (<same_path_as_script_or_inline_script>.lock) and referenced in the yaml by
```
!inline <path of lock>
```
!inline <path of lock>
```
!inline <path of lock>
```
!inline <path of lock>
. We had numerous feedback from EE customers that the lockfile were hard to diff and added lots of boilerplate to otherwise clean yaml files
Script in apps (even frontend scripts) are now stored in separate files, similarly than what is the case for flows. Which mean now apps are their own folders:
```
myapp.yaml -> myapp.app/app.yaml + myapp.app/inline_script1.ts + myapp.app/inline_script1.lock + ....
```
myapp.yaml -> myapp.app/app.yaml + myapp.app/inline_script1.ts + myapp.app/inline_script1.lock + ....
```
myapp.yaml -> myapp.app/app.yaml + myapp.app/inline_script1.ts + myapp.app/inline_script1.lock + ....
```
myapp.yaml -> myapp.app/app.yaml + myapp.app/inline_script1.ts + myapp.app/inline_script1.lock + ....

This will improve greatly the ability to use commits/PR to review scripts, flows and apps changes

To do a clean update:
update your CLI to latest
do a wmill sync pull and push to your repo
update the CLI used to 1.320.3 in your github actions
Update your git sync script (we've made that easier, just click button and save git settings, as in picture)

R

rubenf•5/10/24, 9:01 PM

We are releasing in early Beta a way to deploy typescript scripts with any local relative imports as bundles (similar to what lambda/cloud function does) so that it works with complex local codebases, and any imports or setup without having to publish private packages. It will be an enterprise feature at least at first as it require the instance-wide s3 integration which is where the bundle resides. It works with the vscode extension and you can find some succint documentation here: https://www.windmill.dev/docs/core_concepts/codebases_and_bundles Ping us if you have interest of being part of that beta

Codebases & Bundles | Windmill

Codebases is Beta, only work with typescript and is an enterprise feature for the time being

R

rubenf•5/13/24, 6:38 AM

nativets/REST supports the full wmill api, just use:

import * as wmill from './windmill.ts'

import * as wmill from './windmill.ts'

import * as wmill from './windmill.ts'

import * as wmill from './windmill.ts'

and use it as you would in Bun/Deno

R

rubenf•5/13/24, 6:39 AM

Using the wmill.XService directly in the typescript client (e.g:

wmill.JobService.listJobs(...)

wmill.JobService.listJobs(...)

wmill.JobService.listJobs(...)

wmill.JobService.listJobs(...)) doesn't require to use setClient prior anymore

R

rubenf•5/13/24, 6:56 AM

On the latest windmill and docker-compose template, we mount a log volume across every workers and servers. With the new improvements, will allow you to pull the full log even without EE/S3 if the log volume is also mounted on the servers from which you pull from. We still recommend using the S3 log storage on EE as if you're not using docker-compose, doing multi-write on kubernetes is both complex, slow and expensive.

R

rubenf•5/20/24, 9:35 PM

bun is now the default language on CLI and vscode. Expect some small diffs on latest using

wmill sync pull

wmill sync pull

wmill sync pull

wmill sync pull as a consequence. It's an annoying but necessary last migration.

R

rubenf•5/20/24, 9:38 PM

with the latest batch of memory usage improvements, workers and servers use less memory than ever. A worker (outside of the job) on the cloud take 22MB RSS and our very busy servers sits at 155MB RSS.

R

rubenf•5/23/24, 5:26 PM

Retries are now easier to understand in the flow status viewer:
You can see their numbers as well as the detail of the failed jobs at a glance

W

wendrul•5/27/24, 9:35 AM

New observability features:

You can now see a new graph on the runs page showing the concurrent jobs over time, showing exactly when jobs started and ended.
This will be particularly useful when combined to the also new filter on concurrency keys, to understand concurrency limits better.
https://www.windmill.dev/changelog/concurrency-limit-observability

Concurrency Limit Observability

Obversability around concurrent jobs has been improved from the Runs menu.

H

Hugo•5/29/24, 3:58 PM

New Feature: PHP Support

We are excited to announce that, after many requests, PHP is now supported on Windmill as a primary language! Just like with TypeScript and Python, you can use resource types as parameters. For package management, simply specify the packages you need in comments, and they will be automatically installed and loaded using Composer.

Changelog: https://www.windmill.dev/changelog/concurrency-limit-observability
Docs: https://www.windmill.dev/docs/getting_started/scripts_quickstart/php

R

rubenf•6/4/24, 1:12 PM

many nits in one:

You can now see the full flow/script definition of a job even if it is scheduled in the future (before it would only display when it would be executed)
The flow status viewer now can show the step definition and not just the step status
The flow status viewer now take the whole width on the run page detail of a job
We now display the lockfile in the step detail

W

wendrul•6/4/24, 4:34 PM

More observability:

We've made some changes to the runs page:

There is now a warning on jobs that had to wait some time for an executor before starting.
You can hover the warning to get details about the time spent waiting.

R

rubenf•6/5/24, 3:56 PM

Git sync commits are now prefixed with [WM]
The windmill-sync-example repo has been updated https://github.com/windmill-labs/windmill-sync-example/blob/main/.github/workflows/push-on-merge-staging.yaml#L28-L38 to solve an issue that could arise when doing quick successive deployments if you had bi-directional sync on. It will now not trigger a push in the other direction if the commit come from Windmill (as detected by the presence of [WM]) avoiding out-of-sync overwrite errors.

GitHub

windmill-sync-example/.github/workflows/push-on-merge-staging.yaml ...

Contribute to windmill-labs/windmill-sync-example development by creating an account on GitHub.

R

rubenf•6/10/24, 11:36 AM

Tracking relative imports to avoid dependency hell:

Windmill automatically track relative imports in bun and python such that if you update a common dependency and update its imports, it will now re-trigger deployment and lockfile computation of all the scripts that depend on it (it was working for python but not bun before)
Windmill can now also track such imports in inline scripts of flows and will surgically update the inline lockfiles of those flows if the relative imports change