Conversation
Rename the user-facing concept from "workflow" to "task" across code, resources, configs, tests, and docs. Internal renames are clean; user-facing surfaces keep deprecation aliases so existing setups continue to work: - Default filename: cijoe-task.yaml; falls back to cijoe-workflow.yaml - CLI flag -w/--workflow: still accepted (already deprecated upstream) - Env var CIJOE_DEFAULT_TASK; CIJOE_DEFAULT_WORKFLOW honored with warning - Config key [cijoe.task]; [cijoe.workflow].fail_fast honored with warning - Resource discovery: tasks/ subdir is canonical; legacy workflows/ subdir in third-party packages still discovered (mapped to tasks category) - example_task_* and legacy example_workflow_* both recognized by --example - Workflow class kept as deprecation alias of Task in cijoe.core.resources - process_workflow_output kept as deprecation alias of process_task_output Signed-off-by: Simon A. F. Lund <os@safl.dk>
Tighten phrasing introduced by the rename and fix pre-existing prose issues that became more visible while reviewing the touched files: - Reword intro to avoid colliding with "task" used as a domain term - Reword "scripts of tasks" typo to "scripts or tasks" - Reword broken sentence introducing CIJOE_TASK_FAIL_FAST - Reference an existing step name (inline_commands) in the subset example - Fix grammar/typos: missing article, subject-verb agreement, "convient" - Complete the truncated sentence introducing the script-step example Signed-off-by: Simon A. F. Lund <os@safl.dk>
cijoe's documented install path is pipx, and pipx-shared pip now uses
3.10+ syntax ('@DataClass(slots=True)'). Any user installing cijoe under
3.9 hits:
TypeError: dataclass() got an unexpected keyword argument 'slots'
We can't honestly claim 3.9 support when the install path is broken
there, so drop it:
- pyproject.toml: requires-python = ">=3.10"
- CI test matrix: 3.10-3.13 (was 3.9-3.12)
- Publish job: 3.10 (was 3.9)
Python 3.9 reached EOL in October 2025; this aligns with upstream.
Signed-off-by: Simon A. F. Lund <os@safl.dk>
Coverage Report for CI Build 25405039452Coverage decreased (-0.2%) to 78.571%Details
Uncovered Changes
Coverage Regressions4 previously-covered lines in 1 file lost coverage.
Coverage Stats
💛 - Coveralls |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The YAML intentionally mirrors GitHub Actions in the small (
name,uses,with,run); that part is on purpose and stays. But calling the file itself a "workflow" oversells the resemblance: there are no matrices, no branches, no conditionals, no expressions. A step is either a plain list of shell commands (run:) or an invocation of an expressive Python cijoe script (uses:+with:); that's the whole vocabulary. The shared name sets the wrong expectation about what cijoe does. "Task" keeps the familiar step keys while signalling that the surrounding orchestration is deliberately minimal, and that the expressive power lives in the Python scripts, not in the YAML.This is also part of the runway toward a v1.0 release; concept-level naming is the kind of thing that has to be settled before stabilizing the API, not after.
Backwards compatibility
The rename is staged with deprecation aliases on every user-facing surface (filename, env var, config key, CLI flag, resource subdir, Python class) so existing setups keep working with a warning rather than a break.