create_pull_request method on GithubClient that enables creating a pull request.create_ref method on GithubClient that enables creating a new branch.dlt.run(...).fetch_row_count() for both partitioned and non-partitioned assets. Thanks @kristianandre!PartitionedConfig objects can now return a RunConfig without causing a crash.AssetIn.__new__ typing for the dagster_type argument.fetch_row_count() method now works for databases returning uppercase column names. Thanks @kristianandre!GCSFileManager.read operations. Thanks @ollie-bell!JobDefinition, @job, and define_asset_job now take a run_tags parameter. If run_tags are defined, they will be attached to all runs of the job, and tags will not be. If run_tags is not set, then tags are attached to all runs of the job (status quo behavior). This change enables the separation of definition-level and run-level tags on jobs.DAGSTER_COMPUTE_LOG_TAIL_WAIT_AFTER_FINISH can now be used to pause before capturing logs (thanks @HynekBlaha!)kinds parameter is now available on AssetSpec.OutputContext now exposes the AssetSpec of the asset that is being stored as an output (thanks, @marijncv!)AutomationCondition on an asset, the label of this condition will now be shown in the sidebar on the Asset Details page.dagster definitions validate have been added.AssetSpec now has a with_io_manager_key method that returns an AssetSpec with the appropriate metadata entry to dictate the key for the IO manager used to load it. The deprecation warning for SourceAsset now references this method.max_runtime_seconds configuration option to run monitoring, allowing you to specify that any run in your Dagster deployment should terminate if it exceeds a certain runtime. Prevoiusly, jobs had to be individually tagged with a dagster/max_runtime tag in order to take advantage of this feature. Jobs and runs can still be tagged in order to override this value for an individual run.tags and a custom execution_fn on a ScheduleDefinition. Schedule tags are intended to annotate the definition and can be used to search and filter in the UI. They will not be attached to run requests emitted from the schedule if a custom execution_fn is provided. If no custom execution_fn is provided, then for back-compatibility the tags will also be automatically attached to run requests emitted from the schedule.SensorDefinition and all of its variants/decorators now accept a tags parameter. The tags annotate the definition and can be used to search and filter in the UI.dagster definitions validate command to Dagster CLI. This command validates if Dagster definitions are loadable.build_op_context in a unit test would sometimes raise a TypeError: signal handler must be signal.SIG_IGN, signal.SIG_DFL, or a callable object Exception on process shutdown.DefaultScheduleStatus.STOPPED / DefaultSensorStatus.STOPPED after performing a reset.--partition-range option to dagster asset materialize CLI. This option only works for assets with single-run Backfill Policies..without() method to AutomationCondition.eager(), AutomationCondition.on_cron(), and AutomationCondition.on_missing() which allows sub-conditions to be removed, e.g. AutomationCondition.eager().without(AutomationCondition.in_latest_time_window()).AutomationCondition.on_missing(), which materializes an asset partition as soon as all of its parent partitions are filled in.pyproject.toml can now load multiple Python modules as individual Code Locations. Thanks, @bdart!ADLS2PickleIOManager now accepts lease_duration configuration. Thanks, @0xfabioo!sling.replicate(...).fetch_row_count().AutomationCondition.any_downstream_condition() with downstream AutoMaterializePolicy objects.process_config_and_initialize did not properly handle processing nested resource config.DepConditionWrapperCondition instead of the key that they were evaluated against.wait_for_pod check now waits until all pods are available, rather than erroneously returning after the first pod becomes available. Thanks @easontm!AssetSpec constructor now raises an error if an invalid group name is provided, instead of an error being raised when constructing the Definitions object.dagster/relation_identifier metadata is now automatically attached to assets which are stored using a DbIOManager.DbtCliResource, the project_dir argument will now override the DBT_PROJECT_DIR environment variable if it exists in the local environment (thanks, @marijncv!).rows_loaded metadata (thanks, @kristianandre!).asset_selection=[] on RunRequest objects yielded from sensors using asset_selection would select all assets instead of none.assets_dbt_python example.database field set (thanks, @dargmuesli!)dbt.adapters.duckdb module when loading dbt assets without that package installed.DagsterInstance.wipe_asset_partitions.allow_missing_partitions as metadata on a downstream asset.object has no attribute '_base_path' error.statuses filter argument to the sensorsOrError GraphQL field was sometimes ignored when querying GraphQL for multiple sensors at the same time.CapturedLogManager and ComputeLogManager APIs into a single base class.PipesECSClient to allow Dagster to interface with ECS tasks.dbt subprocess to wait 25 seconds for the subprocess to cleanly terminate. Previously, it would only wait 2 seconds.sdf subprocess to wait 25 seconds for the subprocess to cleanly terminate. Previously, it would only wait 2 seconds.AutomationCondition using DagsterDltTranslator.get_automation_condition() (Thanks, aksestok!)dagsterDaemon.runRetries.retryOnAssetOrOpFailure to False in the Dagster Helm chart to prevent op retries and run retries from simultaneously firing on the same failure.recursive parameter (Thanks, chrishiste!)dagster/image label when image is provided from user_defined_k8s_config. (Thanks, @HynekBlaha!)custom_user_agent, was provided by defaultPipesGlueClient.run have been deprecated and will be removed in 1.9.0. The new params argument should be used instead.allow_missing_partitions configuration option.PartitionsDefinitions, there will no longer be an implicit asset job __ASSET_JOB_... for each PartitionsDefinition; there will just be one with all the assets. This reduces the time it takes to load code locations with assets with many different PartitionsDefinitions.OpenAIResource (Thanks, @chasleslr!)MultiPartitionMapping with @dbt_assets (Thanks, @arookieds!)AzureBlobComputeLogManager without a secret_key (Thanks, @ion-elgreco and @HynekBlaha!)AutomationCondition and associated static constructors.PipesCloudWatchMessageReader[@run_status_sensor](https://docs.dagster.io/_apidocs/schedules-sensors#dagster.run_status_sensor) which defines sensors that react to given PipelineRunStatus.solid on build_hook_context. This allows you to access the hook_context.solid parameter.dagster’s dependency on docstring-parser has been loosened.@pipeline now pulls its description from the doc string on the decorated function if it is provided.dagster new-project now no longer targets a non-existent mode.@repository functions.GraphDefinition.to_job now supports the description argument.AmazonECS_FullAccess policy. Now, the attached roles has been more narrowly scoped to only allow the daemon and dagit tasks to interact with the ECS actions required by the EcsRunLauncher.Error: Got unexpected extra arguments. Now, it ignores the entrypoint and launches succeed.dagster instance migrate.ScheduleDefinition constructor to instantiate a schedule definition, if a schedule name is not provided, the name of the schedule will now default to the pipeline name, plus “_schedule”, instead of raising an error.description and solid_retry_policy were getting dropped when using a solid_hook decorator on a pipeline definition (#4355).@pipeline_failure_sensor that prevented them from working.With the new first-class Pipeline Failure sensors, you can now write sensors to perform arbitrary actions when pipelines in your repo fail using @pipeline_failure_sensor. Out-of-the-box sensors are provided to send emails using make_email_on_pipeline_failure_sensor and slack messages using make_slack_on_pipeline_failure_sensor.
See the Pipeline Failure Sensor docs to learn more.
New first-class Asset sensors help you define sensors that launch pipeline runs or notify appropriate stakeholders when specific asset keys are materialized. This pattern also enables Dagster to infer cross-pipeline dependency links. Check out the docs here!
Solid-level retries: A new retry_policy argument to the @solid decorator allows you to easily and flexibly control how specific solids in your pipelines will be retried if they fail by setting a RetryPolicy.
Writing tests in Dagster is now even easier, using the new suite of direct invocation apis. Solids, resources, hooks, loggers, sensors, and schedules can all be invoked directly to test their behavior. For example, if you have some solid my_solid that you'd like to test on an input, you can now write assert my_solid(1, "foo") == "bar" (rather than explicitly calling execute_solid()).
[Experimental] A new set of experimental core APIs. Among many benefits, these changes unify concepts such as Presets and Partition sets, make it easier to reuse common resources within an environment, make it possible to construct test-specific resources outside of your pipeline definition, and more. These changes are significant and impactful, so we encourage you to try them out and let us know how they feel! You can learn more about the specifics here
[Experimental] There’s a new reference deployment for running Dagster on AWS ECS and a new EcsRunLauncher that launches each pipeline run in its own ECS Task.
[Experimental] There’s a new k8s_job_executor (https://docs.dagster.io/_apidocs/libraries/dagster-k8s#dagster_k8s.k8s_job_executor)which executes each solid of your pipeline in a separate Kubernetes job. This addition means that you can now choose at runtime (https://docs.dagster.io/deployment/guides/kubernetes/deploying-with-helm#executor) between single pod and multi-pod isolation for solids in your run. Previously this was only configurable for the entire deployment- you could either use the K8sRunLauncher with the default executors (in process and multiprocess) for low isolation, or you could use the CeleryK8sRunLauncher with the celery_k8s_job_executor for pod-level isolation. Now, your instance can be configured with the K8sRunLauncher and you can choose between the default executors or the k8s_job_executor.
Using the @schedule, @resource, or @sensor decorator no longer requires a context parameter. If you are not using the context parameter in these, you can now do this:
@schedule(cron_schedule="\* \* \* \* \*", pipeline_name="my_pipeline") def my_schedule(): return {} @resource def my_resource(): return "foo" @sensor(pipeline_name="my_pipeline") def my_sensor(): return RunRequest(run_config={})
Dynamic mapping and collect features are no longer marked “experimental”. DynamicOutputDefinition and DynamicOutput can now be imported directly from dagster.
Added repository_name property on SensorEvaluationContext, which is name of the repository that the sensor belongs to.
get_mapping_key is now available on SolidExecutionContext , allowing for discerning which downstream branch of a DynamicOutput you are in.
When viewing a run in Dagit, you can now download its debug file directly from the run view. This can be loaded into dagit-debug.
[dagster-dbt] A new dbt_cli_resource simplifies the process of working with dbt projects in your pipelines, and allows for a wide range of potential uses. Check out the integration guide for examples!
k8s_job_executor that caused solid tag user defined Kubernetes config to not be applied to the Kubernetes jobs.The deprecated SystemCronScheduler and K8sScheduler schedulers have been removed. All schedules are now executed using the dagster-daemon proess. See the deployment docs for more information about how to use the dagster-daemon process to run your schedules.
If you have written a custom run launcher, the arguments to the launch_run function have changed in order to enable faster run launches. launch_run now takes in a LaunchRunContext object. Additionally, run launchers should now obtain the PipelinePythonOrigin to pass as an argument to dagster api execute_run. See the implementation of DockerRunLauncher for an example of the new way to write run launchers.
[helm] .Values.dagsterDaemon.queuedRunCoordinator has had its schema altered. It is now referenced at .Values.dagsterDaemon.runCoordinator.
Previously, if you set up your run coordinator configuration in the following manner:
dagsterDaemon: queuedRunCoordinator: enabled: true module: dagster.core.run_coordinator class: QueuedRunCoordinator config: max_concurrent_runs: 25 tag_concurrency_limits: [] dequeue_interval_seconds: 30
It is now configured like:
dagsterDaemon: runCoordinator: enabled: true type: QueuedRunCoordinator config: queuedRunCoordinator: maxConcurrentRuns: 25 tagConcurrencyLimits: [] dequeueIntervalSeconds: 30
The method events_for_asset_key on DagsterInstance has been deprecated and will now issue a warning. This method was previously used in our asset sensor example code. This can be replaced by calls using the new DagsterInstance API get_event_records. The example code in our sensor documentation has been updated to use our new APIs as well.