Skip to content

Commit 9edbbd5

Browse files
committed
[docs] fix docs snippet and markdown content
- Add code snippet for backfill config in `dagster.yaml` - Remove redundant section in `workspace-yaml.md` - Fix markdown table and callout
1 parent 4528523 commit 9edbbd5

5 files changed

Lines changed: 19 additions & 19 deletions

File tree

docs/docs/dagster-basics-tutorial/6-custom-components.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -10,7 +10,7 @@ If we think about the code for our three assets (`customers`, `orders`, and `pay
1010

1111
These assets are a great candidate for a [custom component](/guides/build/components/creating-new-components). Components generate `Definitions` through a configuration layer. There are built-in components that let you integrate with common workflows (such as turning Python scripts into assets), or dynamically generate `Definitions` for tools like [dbt](/integrations/libraries/dbt) or [Fivetran](/integrations/libraries/fivetran). With custom components, you can define your own specific use cases.
1212

13-
In this step, you will use a custom component to streamline the development of similar assets and replace their `Definitions` in your project with a Component that can generate them from a a YAML configuration file instead.
13+
In this step, you will use a custom component to streamline the development of similar assets and replace their `Definitions` in your project with a Component that can generate them from a YAML configuration file instead.
1414

1515
![2048 resolution](/images/tutorial/dagster-tutorial/overviews/components.png)
1616

docs/docs/deployment/oss/deployment-options/docker.md

Lines changed: 4 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -10,8 +10,10 @@ This guide provides instructions for deploying Dagster using Docker Compose. Thi
1010
The [full example is available on GitHub](https://github.com/dagster-io/dagster/blob/master/examples/deploy_docker).
1111

1212
<details>
13-
<summary>Prerequisites</summary>- Familiarity with Docker and Docker Compose - Familiarity with `dagster.yaml`
14-
instance configuration - Familiarity with `workspace.yaml` code location configuration
13+
<summary>Prerequisites</summary>
14+
- Familiarity with Docker and Docker Compose
15+
- Familiarity with `dagster.yaml` instance configuration
16+
- Familiarity with `workspace.yaml` code location configuration
1517
</details>
1618

1719
## Define a Docker image for the Dagster webserver and daemon

docs/docs/deployment/oss/oss-deployment-architecture.md

Lines changed: 6 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -47,12 +47,12 @@ Dagster's provided [Kubernetes Helm chart deployment](/deployment/oss/deployment
4747

4848
Job execution flows through several parts of the Dagster system. The following table describes runs launched by the UI, specifically the components that handle execution and the order in which they are executed.
4949

50-
| Order | Component | Description | Configured by |
51-
| --------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- | ------------- |
52-
| [Run coordinator](/deployment/execution/run-coordinators) | The run coordinator is a class invoked by the webserver process when runs are launched from the Dagster UI. This class can be configured to pass runs to the daemon via a queue. | Instance |
53-
| [Run launcher](/deployment/execution/run-launchers) | The run launcher is a class invoked by the daemon when it receives a run from the queue. This class initializes a new run worker to handle execution. Depending on the launcher, this could mean spinning up a new process, container, Kubernetes pod, etc. | Instance |
54-
| Run worker | The run worker is a process which traverses a graph and uses the executor to execute each op. | n/a |
55-
| [Executor](/guides/operate/run-executors) | The executor is a class invoked by the run worker for running user ops. Depending on the executor, ops run in local processes, new containers, Kubernetes pods, etc. | Run config |
50+
| Order | Component | Description | Configured by |
51+
| ----- | --------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------- |
52+
| 1 | [Run coordinator](/deployment/execution/run-coordinators) | The run coordinator is a class invoked by the webserver process when runs are launched from the Dagster UI. This class can be configured to pass runs to the daemon via a queue. | Instance |
53+
| 2 | [Run launcher](/deployment/execution/run-launchers) | The run launcher is a class invoked by the daemon when it receives a run from the queue. This class initializes a new run worker to handle execution. Depending on the launcher, this could mean spinning up a new process, container, Kubernetes pod, etc. | Instance |
54+
| 3 | Run worker | The run worker is a process which traverses a graph and uses the executor to execute each op. | n/a |
55+
| 4 | [Executor](/guides/operate/run-executors) | The executor is a class invoked by the run worker for running user ops. Depending on the executor, ops run in local processes, new containers, Kubernetes pods, etc. | Run config |
5656

5757
Additionally, note that runs launched by schedules and sensors go through the same flow, but the first step is called by the [Dagster daemon](/deployment/execution/dagster-daemon) instead of the webserver.
5858

docs/docs/guides/build/projects/workspaces/workspace-yaml.md

Lines changed: 0 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -32,16 +32,6 @@ To accommodate incrementally migrating from `@repository` to `Definitions`, code
3232

3333
:::
3434

35-
## Location of workspace.yaml
36-
37-
Dagster command-line tools (like `dg`) look for workspace files in the current directory when invoked. This allows you to launch from that directory without the need for command line arguments
38-
39-
To load the workspace.yaml file from a different folder, use the -w argument:
40-
41-
```bash
42-
dg dev -w path/to/workspace.yaml
43-
```
44-
4535
## File structure
4636

4737
The `workspace.yaml` file uses the following structure:

examples/docs_snippets/docs_snippets/deploying/dagster_instance/dagster.yaml

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -406,6 +406,14 @@ schedules:
406406

407407
# end_marker_schedules
408408

409+
# start_marker_backfills
410+
411+
backfills:
412+
use_threads: true
413+
num_workers: 8
414+
415+
# end_marker_backfills
416+
409417
auto_materialize:
410418
run_tags:
411419
key: value

0 commit comments

Comments
 (0)