From 6d26ce48879ebb8f1917dbd6cec6eb73d2c14b2d Mon Sep 17 00:00:00 2001 From: Blai Peidro Date: Sun, 13 Sep 2026 23:48:55 +0200 Subject: [PATCH 1/3] docs: add examples for the cancel, approve and deny actions #61 gave relaunch a section in the CLI usage examples. #62, #63 and #64 added cancel, approve and deny without one, so the only place they appear is the generated command reference, and that page is built from a live server's OPTIONS metadata rather than from the tree. Anybody reading the docs as checked in sees nothing about them. Cancel gets the list of resources it works on and the note that the status printed back can still read running, since the platform stops the job shortly after accepting the request rather than before answering. Approve and deny share a section, being the two answers to the same question. --- ascenderkit/cli/docs/source/examples.rst | 29 ++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/ascenderkit/cli/docs/source/examples.rst b/ascenderkit/cli/docs/source/examples.rst index c9426f2..95bed20 100644 --- a/ascenderkit/cli/docs/source/examples.rst +++ b/ascenderkit/cli/docs/source/examples.rst @@ -56,6 +56,35 @@ alone: ascender jobs relaunch 42 --hosts failed ascender workflow_jobs relaunch 7 --nodes failed --wait +Cancelling a Running Job +------------------------ + +Cancelling is available on every job resource: ``jobs``, ``workflow_jobs``, +``project_updates``, ``inventory_updates``, ``ad_hoc_commands`` and +``system_jobs``. The platform accepts the request and stops the job shortly +after, so the status printed back can still read ``running``. Asking to cancel a +job that has already finished returns the platform's own refusal: + +.. code:: bash + + ascender jobs cancel 42 + ascender workflow_jobs cancel 7 -f human + ascender project_updates cancel 13 + +Approving or Denying a Workflow Approval +---------------------------------------- + +A workflow that reaches an approval node waits there until somebody answers it. +Approving lets the workflow past the node, denying refuses it and fails the +workflow. Both print the approval as it stands afterwards, so the status in the +output is the one it has once the answer has landed: + +.. code:: bash + + ascender workflow_approvals list -f human + ascender workflow_approvals approve 21 + ascender workflow_approvals deny 22 + Updating a Job Template with Extra Vars --------------------------------------- From 317b77ad56808c26fe216dc7c3ad36da1ec46396 Mon Sep 17 00:00:00 2001 From: Blai Peidro Date: Sun, 13 Sep 2026 23:51:14 +0200 Subject: [PATCH 2/3] docs: add examples for the test action #65 added test on notification_templates, credentials and credential_types and landed without an examples entry, the same gap as the three actions above it. It gets more room than they do because --inputs and --metadata are the part a generated signature cannot convey: they carry values that are not saved yet, which is the point of the endpoint, and either one takes JSON or YAML or @ a file holding it. --- ascenderkit/cli/docs/source/examples.rst | 26 ++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/ascenderkit/cli/docs/source/examples.rst b/ascenderkit/cli/docs/source/examples.rst index 95bed20..ca35785 100644 --- a/ascenderkit/cli/docs/source/examples.rst +++ b/ascenderkit/cli/docs/source/examples.rst @@ -85,6 +85,32 @@ output is the one it has once the answer has landed: ascender workflow_approvals approve 21 ascender workflow_approvals deny 22 +Testing a Notification Template or a Credential +----------------------------------------------- + +Testing asks the platform to exercise a thing rather than describe it, on +``notification_templates``, ``credentials`` and ``credential_types``. Testing a +notification template sends one, and the reply names the notification it queued, +whose own record carries the delivery status. Testing a lookup credential +performs the lookup and reports what came back: + +.. code:: bash + + ascender notification_templates test 3 -f human + ascender credentials test 9 + +``--inputs`` and ``--metadata`` try values that are not saved yet, which is what +the endpoint is for: trying a configuration before committing to it. Both take +JSON or YAML, or ``@`` a file holding either: + +.. code:: bash + + ascender credentials test 9 \ + --metadata '{"secret_path": "/kv/prod", "secret_key": "password"}' + ascender credential_types test 12 \ + --inputs '{"url": "https://vault.example.org", "token": "@~/.vault-token"}' \ + --metadata @lookup.yml + Updating a Job Template with Extra Vars --------------------------------------- From 663dd8b5f605ebcc38e5304ab5d3d88bca9e2129 Mon Sep 17 00:00:00 2001 From: Blai Peidro Date: Mon, 14 Sep 2026 00:09:44 +0200 Subject: [PATCH 3/3] build: point the Dependabot pip comment at pyproject.toml The comment said Dependabot reads the install_requires and extras_require lists straight out of setup.py. #37 moved the packaging metadata to PEP 621, so those lists are the dependencies and optional-dependencies tables in pyproject.toml and setup.py holds neither: it is version resolution only and declares nothing to bump. Comment only. Dependabot reads pyproject either way, so nothing about what gets bumped changes. The reason to fix it is that the convention keeps these comments for the reasoning a reviewer cannot reconstruct, and this one pointed at the wrong file. --- .github/dependabot.yml | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/.github/dependabot.yml b/.github/dependabot.yml index 22fbd5e..ace79dc 100644 --- a/.github/dependabot.yml +++ b/.github/dependabot.yml @@ -22,8 +22,9 @@ updates: - ci - package-ecosystem: pip - # the install_requires and extras_require lists, which Dependabot reads - # straight out of setup.py + # the dependencies and optional-dependencies tables in pyproject.toml, which + # is where the packaging metadata moved in #37. setup.py is version + # resolution only now and declares nothing to bump. directory: / schedule: interval: weekly