Version 5.1.0-alpha.1
Pre-releaseRelease Notes
This release adds support for task parallelization, automatically executing tasks in parallel where possible. It additionally enables optional task multi-instancing, enabling duplicate invocations of tasks with different parameters.
Task Parallelization
By default, nothing about the execution order of tasks will change. They will execute sequentially exactly as they did before. However, tasks can now be marked as sandboxed to enable parallel execution:
[tasks.example]
type = "custom"
sandboxed = truesandboxed in the context of renconstruct is a promise from the user that the task will not modify any global state or have any side effects outside of the task's own scope. For example, a task that creates a file will do so in a way that does not affect itself if it were run with different parameters.
Under this guarantee, reconstruct will execute tasks in parallel if they are marked as sandboxed, occur in the same build stage and have the same priority level. Thus, if task A runs pre-build and task B runs post-build, they can not be executed in parallel.
However, if task A and task B are both marked as sandboxed and occur in the same stage with the same priority level, they can be executed in parallel. renconstruct will automatically detect parallelism opportunities and inform you of this in the logs.
Task Multi-Instancing
The ability to run tasks in parallel also made it more sensible for tasks to be able to run multiple instances of themselves. This is useful for tasks that themselves don't have any internal parallelism opportunities, but can be run multiple times in parallel, for example image processing tasks like resizing to various scales for different directories.
As such, tasks now take a new, optional parameter name which is used to identify the task instance and takes over the duty of the section title in the configuration file.
[tasks.example] # <== This previously determined the task that would run
type = "custom"
[tasks.my_random_identifier] # <== Tasks can now have arbitrary names, allowing multi-instancing
type = "custom"
name = "example" # <== This is now a task parameterBefore this change, the names of task sections in the config file were a limiting factor as only one section could be named tasks.example and could thus refer to that specific custom task. Now tasks can be named arbitrarily, allowing for multiple instances of the same task to be run in parallel. The following invokes the task ExamleTask twice, with different names:
[tasks.random_task_id_1]
type = "custom"
name = "example"
[tasks.random_task_id_2]
type = "custom"
name = "example"To remain backwards-compatible with existing configuration files, the task section names will be used as a fallback when the name parameter is not specified, but a warning will be printed to the console to update to the new format.
Install renkit 5.1.0-alpha.1
Install prebuilt binaries via shell script
curl --proto '=https' --tlsv1.2 -LsSf https://github.com/kobaltcore/renkit/releases/download/v5.1.0-alpha.1/renkit-installer.sh | shInstall prebuilt binaries via powershell script
powershell -ExecutionPolicy Bypass -c "irm https://github.com/kobaltcore/renkit/releases/download/v5.1.0-alpha.1/renkit-installer.ps1 | iex"Install prebuilt binaries via Homebrew
brew install kobaltcore/renkit/renkitDownload renkit 5.1.0-alpha.1
| File | Platform | Checksum |
|---|---|---|
| renkit-aarch64-apple-darwin.tar.xz | Apple Silicon macOS | checksum |
| renkit-x86_64-apple-darwin.tar.xz | Intel macOS | checksum |
| renkit-x86_64-pc-windows-msvc.zip | x64 Windows | checksum |
| renkit-aarch64-unknown-linux-gnu.tar.xz | ARM64 Linux | checksum |
| renkit-x86_64-unknown-linux-gnu.tar.xz | x64 Linux | checksum |
| renkit-x86_64-unknown-linux-musl.tar.xz | x64 MUSL Linux | checksum |