All Versions
59
Latest Version
Avg Release Cycle
7 days
Latest Release
-

Changelog History
Page 3

  • v2.0.b15 Changes

    Uniquely refer to blocks with slugs

    Blocks are a convenient way to secure store and retrieve configuration. Now, retrieving configuration stored with blocks is even easier with slugs, both human and machine readable unique identifiers. By default, block type slugs are a lowercase, dash delimited version of the block type name, but can be customized via the _block_type_slug field on a custom Block subclass. Block document slugs are a concatenation of [block-type-slug]/[block-document-name] and can be used as an argument to the Block.load method. Slugs and block document names may only include alphanumeric characters and dashes.

    โš  Warning: This breaking change makes this release incompatible with previous versions of the Orion server and Prefect Cloud 2.0

    ๐Ÿ›  Other improvements and bug fixes

  • v2.0.b14 Changes

    Retreive the state of your tasks or flows with the return_state kwarg

    Beginning with 2.0b9, Prefect 2.0 began returning function results, instead of Prefect futures and states, by default. States are still an important concept in Prefect 2. They can be used to dictate and understand the behavior of your flows. Now, you can access the state for any task or flow with the new return_state kwarg. Just set return_state=True in you flow or task call and you can access its state with the .result() method, even if it's been submitted to a task runner.

    prefect cloud commands are easier to use

    ๐ŸŒฒ The prefect cloud login command no longer overwrites your current profile with a new API URL and auth key. Instead, the command will prompt you to create a new profile when logging into Prefect Cloud 2.0. Subsequent calls to prefect cloud login using the same key will simply "log in" to prefect cloud by switching to the profile associated with that authentication key.

    The new prefect cloud workspace ls command lists availible workspaces.

    ๐Ÿ›  Other improvements and bug fixes

    • โฑ The anchor datetime (aka start datetime) for all newly created interval schedules will be the current date & time
    • The prefect orion start command now handles keyboard interrupts
    • ๐ŸŽ CLI performance has been sped up 30-40% through improved import handling
    • ๐Ÿ“š UI screenschots have been updated throughout the documentation
    • Broken links don't feel as bad with our slick new 404 page
  • v2.0.b13 Changes

    ๐Ÿ‘Œ Improvements and bug fixes

    • โฑ RRule schedule strings are now validated on initialization to confirm that the provided RRule strings are valid
    • โšก๏ธ Concepts docs have been updated for clarity and consistency
    • โฑ IntervalSchedule's now coerce naive datetimes to timezone-aware datetimes, so that interval schedules created with timezone-unaware datetimes will work
  • v2.0.b12 Changes

    Work queue pages now display upcoming runs

    ๐Ÿ‘€ A new "Upcoming runs" tab has been added to the work queue page, enabling you to see all of the runs that are eligible for that work queue before they are picked up by an agent.

    ๐Ÿ›  Other improvements and bug fixes

    • You can now set a concurrency limit when creating a work queue via the CLI
    • In order to avoid unwittingly breaking references to shared blocks, block names are no longer editable
    • ๐Ÿ“š Getting started documentation has been updated and edited for clarity
    • ๐Ÿ“š Blocks API documentation has been updated to include system, kubernetes, and notifications block modules
  • v2.0.b11 Changes

    ๐Ÿš€ This release builds upon the collection of small enhancements made in the previous release.

    ๐Ÿšš Default storage has been removed

    For convenience, earlier versions of Prefect 2.0 allowed for a global storage setting. With forthcoming enhancements to blocks, this will no longer be necessary.

    ๐Ÿ›  Other improvements and bug fixes

    • ๐Ÿ“„ We have published a guide for migrating workflows from Prefect 1.0 (and lower) to Prefect 2.0
    • The Flow run page now has a clearer empty state that is more consistent with other pages
    • ๐Ÿ“š Tutorial documentation has been further updated to reflect new result behavior
    • Tasks and flows now run in interruptible threads when timeouts are used
    • ๐Ÿ‘ Parameter validation no longer fails on unsupported types
    • ๐Ÿ’ป The UI now returns you to the blocks overview after deleting a block
    • โšก๏ธ Flow run logs have been updated to improve user visibility into task runner usage
    • Concurrency limits of 0 are now respected on work queues
  • v2.0.b10 Changes

    ๐Ÿš€ This release is the first of a series of smaller releases to be released daily.

    ๐Ÿ‘Œ Improvements and bug fixes

    • ๐Ÿ“‡ The Blocks selection page now includes more complete and consistent metadata about each block type, including block icons, descriptions, and examples
    • ๐Ÿ’… We've added a new CLI style guide for contributors
    • Work queues no longer filter on flow runner types, this capability will instead be achieved through tags
    • ๐Ÿ“š Tutorial documentation has been updated to reflect new result behavior
  • v2.0.b1 Changes

    We are excited to introduce this branch as Prefect 2.0, powered by Orion, our second-generation orchestration engine! We will continue to develop Prefect 2.0 on this branch. Both the Orion engine and Prefect 2.0 as a whole will remain under active development in beta for the next several months, with a number of major features yet to come.

    ๐Ÿš€ This is the first release that's compatible with Prefect Cloud 2.0's beta API - more exciting news to come on that soon!

    ๐Ÿ’ป Expanded UI

    ๐Ÿš€ Through our technical preview phase, our focus has been on establishing the right concepts and making them accessible through the CLI and API. Now that some of those concepts have matured, we've made them more accessible and tangible through UI representations. This release adds some very important concepts to the UI:

    ๐Ÿš€ Flows and deployments

    ๐Ÿš€ If you've ever created a deployment without a schedule, you know it can be difficult to find that deployment in the UI. This release gives flows and their deployments a dedicated home on the growing left sidebar navigation. The dashboard continues to be the primary interface for exploring flow runs and their task runs.

    Work queues

    ๐Ÿš€ With the 2.0a13 release, we introduced work queues, which could only be created through the CLI. Now, you can create and edit work queues directly from the UI, then copy, paste, and run a command that starts an agent that pulls work from that queue.

    Collections

    ๐Ÿ— Prefect Collections are groupings of pre-built tasks and flows used to quickly build data flows with Prefect.

    Collections are grouped around the services with which they interact. For example, to download data from an S3 bucket, you could use the s3_download task from the prefect-aws collection, or if you want to send a Slack message as part of your flow you could use the send_message task from the prefect-slack collection.

    ๐Ÿ‘€ By using Prefect Collections, you can reduce the amount of boilerplate code that you need to write for interacting with common services, and focus on the outcome you're seeking to achieve. Learn more about them in the docs.

    Profile switching

    We've added the prefect profile use <name> command to allow you to easily switch your active profile.

    โšก๏ธ The format for the profiles file has changed to support this. Existing profiles will not work unless their keys are updated.

    For example, the profile "foo" must be changed to "profiles.foo" in the file profiles.toml:

    [foo]
    SETTING = "VALUE"
    

    to

    [profiles.foo]
    SETTING = "VALUE"
    

    Other enhancements

    • ๐Ÿš€ It's now much easier to explore Prefect 2.0's major entities, including flows, deployments, flow runs, etc. through the CLI with the ls command, which produces consistent, beautifully stylized tables for each entity.
    • ๐Ÿ‘Œ Improved error handling for issues that the client commonly encounters, such as network errors, slow API requests, etc.
    • ๐Ÿ’… The UI has been polished throughout to be sleeker, faster, and even more intuitive.
    • โœ… We've made it even easier to access file storage through fsspec, which includes many useful built in implementations.
  • v2.0.a9 Changes

    ๐Ÿ”Š Logs

    ๐Ÿš€ This release marks another major milestone on Orion's continued evolution into a production ready tool. Logs are fundamental output of any orchestrator. Orion's logs are designed to work exactly the way that you'd expect them to work. Our logger is built entirely on Python's standard library logging configuration hooks, so you can easily output to JSON, write to files, set levels, and more - without Orion getting in the way. All logs are associated with a flow run ID. Where relevant, they are also associated with a task run ID.

    ๐Ÿš€ Once you've run your flow, you can find the logs in a dedicated tab on the flow run page, where you can copy them all or one line at a time. You can even watch them come in as your flow run executes. Future releases will enable further filter options and log downloads. ๐Ÿ”Š Learn more about logging in the docs.

    Other Enhancements

    โฑ In addition to logs, we also included the scheduler in the set of services started with prefect orion start. Previously, this required a dedicated flag or an additional command. Now, the scheduler is always available while Orion is running.

  • v2.0.a8 Changes

    ๐Ÿš€ The 2.0a7 release required users to pull Docker images (e.g. docker pull prefecthq/prefect:2.0a7-python3.8) before the agent could run flows in Docker.

    ๐Ÿš€ This release adds pull policies to the DockerFlowRunner allowing full control over when your images should be pulled from a registry. We infer reasonable defaults from the tag of your image, following the behavior of Kubernetes image pull policies.

  • v2.0.a7 Changes

    Flow Runners

    ๐Ÿš€ On the heels of the recent rename of Onion's Executor to TaskRunner, this release introduces FlowRunner, an analogous concept that specifies the infrastructure that a flow runs on. Just as a task runner can be specified for a flow, which encapsulates tasks, a flow runner can be specified for a deployment, which encapsulates a flow. This release includes two flow runners, which we expect to be the most commonly used:

    • SubprocessFlowRunner - The subprocess flow runner is the default flow runner. It allows for specification of a runtime Python environment with virtualenv and conda support.
    • ๐Ÿณ DockerFlowRunner - Executes the flow run in a Docker container. The image, volumes, labels, and networks can be customized. From this release on, Docker images for use with this flow runner will be published with each release.

    ๐Ÿš€ Future releases will introduce runners for executing flows on Kubernetes and major cloud platform's container compute services (e.g. AWS ECS, Google Cloud Run).

    Other enhancements

    In addition to flow runners, we added several other enhancements and resolved a few issues, including:

    • ๐Ÿ“„ Corrected git installation command in docs
    • โšก๏ธ Refined UI through color, spacing, and alignment updates
    • Resolved memory leak issues associated with the cache of session factories
    • ๐Ÿ‘Œ Improved agent locking of double submitted flow runs and handling for failed flow run submission