add dependency-update workflow template (fixes #683) by Rimsha2535 · Pull Request #756 · exasol/python-toolbox

Rimsha2535 · 2026-03-19T14:29:48Z

Fixes #683

Checklist

Note: If any of the items in the checklist are not relevant to your PR, just check the box.

For any Pull Request

Is the following correct:

the title of the Pull Request?
the title of the corresponding issue?
there are no other open [Pull Requests](../../../../pulls) for the same update/change?
that the issue which this Pull Request fixes ("Fixes...") is mentioned?

When Changes Were Made

Did you:

update the changelog?
update the cookiecutter-template?
update the implementation?
check coverage and add tests: unit tests and, if relevant, integration tests?
update the User Guide & other documentation?
resolve any failing CI criteria (incl. Sonar quality gate)?

When Preparing a Release

Have you:

thought about version number (major, minor, patch)?
checked Exasol packages for updates and resolved open vulnerabilities, if easily possible?

Notes

Changelog was not updated because this is an internal workflow/template change.
No separate cookiecutter-template update was needed because the workflow template itself was updated.
CI checks are currently failing and will be fixed.

ArBridgeman · 2026-03-31T07:56:26Z

+
+      - name: Audit Dependencies
+        id: audit-dependencies
+        run: poetry run -- nox -s dependency:audit


We can ask the users of the python-toolbox what they'd prefer.

When I'd written that we perform a check by running poetry run -- nox -s dependency:audit, I had thought we could check to see if there are vulnerabilities detected or not. If there were vulnerabilities, then we'd proceed with updating the dependencies. Otherwise, we would skip the update.

One way to do this would be to check the length of the produced JSON;

# this will both print the results & output them to a json file poetry run -- nox -s dependency:audit | tee vulnerabilities.json LENGTH=$(jq 'length' vulnerabilities.json) echo "count=$LENGTH" >> $GITHUB_OUTPUT

In the next step, where we run update-dependencies, we can add an if-statement

if: steps.audit-dependencies.outputs.count > 0

sonarqubecloud · 2026-04-15T07:50:30Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

ArBridgeman · 2026-04-15T06:51:55Z

       ``report.yml``. See :ref:`ci_yml` for a graph of workflow calls.
+   * - ``dependency-update.yml``
+     - Weekly and manual
+     - Audits project dependencies for known vulnerabilities, updates them with Poetry when needed, and creates a pull request if ``poetry.lock`` changes.


Suggested change

- Audits project dependencies for known vulnerabilities, updates them with Poetry when needed, and creates a pull request if ``poetry.lock`` changes.

- Audits project dependencies for known vulnerabilities, updates them with Poetry when needed, and creates a pull request if the ``poetry.lock`` was changed.

ArBridgeman · 2026-04-15T06:52:40Z

+It can be triggered manually and is also scheduled to run weekly.
+
+The workflow first audits dependencies for known vulnerabilities. If vulnerabilities
+are detected, it updates the dependencies using Poetry. When ``poetry.lock`` changes,


Suggested change

are detected, it updates the dependencies using Poetry. When ``poetry.lock`` changes,

are detected, it updates the dependencies using Poetry. When the ``poetry.lock`` is changed,

ArBridgeman · 2026-04-15T06:53:15Z

+
+The workflow first audits dependencies for known vulnerabilities. If vulnerabilities
+are detected, it updates the dependencies using Poetry. When ``poetry.lock`` changes,
+it creates a pull request with the update.


Suggested change

it creates a pull request with the update.

then it creates a pull request with the update.

ArBridgeman · 2026-04-15T06:54:49Z

+Dependency Update
+^^^^^^^^^^^^^^^^^
+
+The ``dependency-update.yml`` workflow helps keep project dependencies up to date.


Suggested change

The ``dependency-update.yml`` workflow helps keep project dependencies up to date.

The ``dependency-update.yml`` workflow is used to resolve vulnerabilities by updating our project dependencies.

ArBridgeman · 2026-04-15T07:54:51Z

+
 .. _ci_yml:

 Pull Request


You should also add a changelog entry for this in doc/changes/unreleased.md.
You can check out doc/changes/changes_6.3.0.md for inspiration.

For adding it to the changelog:

Add an entry under the section Features. We tend to keep these to a short sentence description that follows the format:

#<GitHub issue number>: <Past tense verb> <clause describing the changes>

Depending on the change, we add a longer description under Summary. In this case, I think it's worthwhile to add a few sentences and link to the documentation . This is because the CI will change for other projects due to this.

(special note) Currently, the anchor for the documentation you wrote doesn't exist yet on main, so it is not published to our active docs. We, however, do not verify anchors (https://github.com/exasol/python-toolbox/blob/main/doc/conf.py#L90), so I believe you can just add it like:
https://exasol.github.io/python-toolbox/main/user_guide/features/github_workflows/index.html#dependency-update

ArBridgeman · 2026-04-15T07:58:00Z

@@ -0,0 +1,93 @@
+name: Dependency Update


We also need to add documentation to:
https://exasol.github.io/python-toolbox/main/user_guide/configuration.html

To do that, we typically create a sub-page in the relevant area. In this case, we have a nice page that we can add to:
https://exasol.github.io/python-toolbox/main/user_guide/features/github_workflows/github_project_configuration.html#

Under the section Secret, we should add the Slack token name, similar to how the PYPI_TOKEN was done. Maybe then, we should also provide a link using RST (not a hyperlink) to your Dependency Update section you wrote, but we could also leave that away.

The Slack token name is INTEGRATION_TEAM_SECURITY_UPDATES_WEBHOOK,
and it's used for the SLACK_WEBHOOK_URL. We don't need to put SLACK_WEBHOOK_URL in the description, but it might be helpful to know that for what you're writing 😉

ArBridgeman · 2026-04-15T08:10:55Z

The GitHub workflow code looked good, but it's always good test, so here are those tests done via
another branch (nearly identical to this one):

Use cases:

✅ No vulnerability detected, so no update
https://github.com/exasol/python-toolbox/actions/runs/24443525540/job/71414050584
✅ Vulnerability detected, do an update, & create PR
https://github.com/exasol/python-toolbox/actions/runs/24444147768/job/71416082184

Example PR:
#780

Like @ckunki said, we likely need to modify this text more to tell the user what to do. But it sounds like this would be done in a later effort.

ArBridgeman · 2026-04-15T08:29:17Z

+
+      - name: Create branch
+        id: create-branch
+        if: steps.check-for-poetry-lock-changes.outputs.changed == 'true' && github.ref == 'refs/heads/main'


From Create Branch and down, we should adapt the if-statements.
I think it might be best if we introduced a check earlier on and set one variable for it.
Then, we don't need to do each of them in full again.

Discussion

Like I said, the default branch can differ for our projects between main and master

format('refs/heads/{0}', github.event.repository.default_branch)

We mostly want to check if it's the default branch as we allow manual execution with workflow_dispatch. Perhaps in the future, we'll expand that, but we don't need that for now.

Suggested Execution Plan

Add a step under Check out Repository where we check the default_branch. This would pass or fail and look similar to the following code. The output and such should be adapted so the default branch value is shown as well as the branch it's being executed on.

- name: Fail if not running on the default branch id: check-branch if: github.ref == format('refs/heads/{0}', github.event.repository.default_branch uses: actions/github-script@v8 with: script: | core.setFailed('Not running on the default branch, github.ref is ${{ github.ref }}. Please start this workflow only on the default branch.')

Then, we can simplify the later if-statements by removing the branch checks for these steps:

Create branch

Commit changes & push

Create pull request

ArBridgeman · 2026-04-15T08:31:59Z

+
+          gh pr create \
+            --base "$BASE_BRANCH" \
+            --title "Update poetry.lock" \


Suggested change

--title "Update poetry.lock" \

--title "Update dependencies to fix vulnerabilities" \

I assume the PRs to accumulate quite quick.
Should we assign a unique ID to the PR's title?

E.g.

the date, or

the dependencies, or vulnerabilities (probably too long and fuzzy)

I like that idea. We could include the date, as we've also got it in the branch name

ckunki · 2026-04-15T09:54:42Z

+
+          This PR was created by the dependency update workflow after running:
+          - \`poetry run -- nox -s dependency:audit\`
+          - \`poetry update\`"


ckunki

Added 2 comments

ckunki · 2026-04-15T10:05:42Z

+        assert "build-and-publish" in result.output
+        assert "cd" in result.output
+        assert "check-release-tag" in result.output
+        assert "checks" in result.output
+        assert "ci" in result.output
+        assert "dependency-update" in result.output
+        assert "gh-pages" in result.output
+        assert "matrix-all" in result.output
+        assert "matrix-exasol" in result.output
+        assert "matrix-python" in result.output
+        assert "merge-gate" in result.output
+        assert "pr-merge" in result.output
+        assert "report" in result.output
+        assert "slow-checks" in result.output


Suggested change

assert "build-and-publish" in result.output

assert "cd" in result.output

assert "check-release-tag" in result.output

assert "checks" in result.output

assert "ci" in result.output

assert "dependency-update" in result.output

assert "gh-pages" in result.output

assert "matrix-all" in result.output

assert "matrix-exasol" in result.output

assert "matrix-python" in result.output

assert "merge-gate" in result.output

assert "pr-merge" in result.output

assert "report" in result.output

assert "slow-checks" in result.output

expected_substrings = """

build-and-publish

cd

check-release-tag

checks

ci

dependency-update

gh-pages

matrix-all

matrix-exasol

matrix-python

merge-gate

pr-merge

report

slow-checks

"""

actual = set(result.output.split())

expected = set(expected_substrings.split())

assert expected.issubset(actual)

tkilias · 2026-04-16T07:20:36Z

+        run: |
+          branch_name="dependency-update/$(date "+%Y%m%d%H%M%S")"
+          echo "Creating branch $branch_name"
+          git checkout -b "$branch_name"


Suggested change

git checkout -b "$branch_name"

git switch -C "$branch_name"

Switch is recommended instead of checkout for creating and changing branches

added dependency-update workflow template

fdf9333

Rimsha2535 requested a deployment to manual-approval March 19, 2026 14:29 — with GitHub Actions Waiting

Rimsha2535 requested a review from kratz00 March 19, 2026 14:30

kratz00 changed the title ~~add dependency-update workflow template~~ add dependency-update workflow template (fixes #683) Mar 19, 2026

Rimsha2535 requested a review from ArBridgeman March 30, 2026 12:41

ArBridgeman reviewed Mar 31, 2026

View reviewed changes

Add dependency-update workflow template and update tests

67e8357

Rimsha2535 requested a deployment to manual-approval April 13, 2026 13:24 — with GitHub Actions Waiting

Merge branch 'main' into feature/dependency-update-workflow

e764019

Rimsha2535 requested a deployment to manual-approval April 13, 2026 13:26 — with GitHub Actions Waiting

Rimsha2535 requested a review from ArBridgeman April 13, 2026 13:27

ArBridgeman reviewed Apr 14, 2026

View reviewed changes

Rimsha2535 requested a deployment to manual-approval April 14, 2026 14:19 — with GitHub Actions Waiting

Apply review feedback for dependency update workflow

c9c53e6

Rimsha2535 requested a review from ArBridgeman April 14, 2026 14:35

Merge branch 'main' into feature/dependency-update-workflow

c05e242

ArBridgeman requested a deployment to manual-approval April 15, 2026 07:46 — with GitHub Actions Waiting

ArBridgeman reviewed Apr 15, 2026

View reviewed changes

ckunki reviewed Apr 15, 2026

View reviewed changes

ckunki requested changes Apr 15, 2026

View reviewed changes

tkilias reviewed Apr 16, 2026

View reviewed changes

	- Audits project dependencies for known vulnerabilities, updates them with Poetry when needed, and creates a pull request if ``poetry.lock`` changes.
	- Audits project dependencies for known vulnerabilities, updates them with Poetry when needed, and creates a pull request if the ``poetry.lock`` was changed.

	are detected, it updates the dependencies using Poetry. When ``poetry.lock`` changes,
	are detected, it updates the dependencies using Poetry. When the ``poetry.lock`` is changed,

	it creates a pull request with the update.
	then it creates a pull request with the update.

	The ``dependency-update.yml`` workflow helps keep project dependencies up to date.
	The ``dependency-update.yml`` workflow is used to resolve vulnerabilities by updating our project dependencies.

	--title "Update poetry.lock" \
	--title "Update dependencies to fix vulnerabilities" \

Conversation

Rimsha2535 commented Mar 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Checklist

For any Pull Request

When Changes Were Made

When Preparing a Release

Notes

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

sonarqubecloud bot commented Apr 15, 2026

Quality Gate passed

Uh oh!

ArBridgeman Apr 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ArBridgeman Apr 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ArBridgeman Apr 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ArBridgeman Apr 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ArBridgeman commented Apr 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ArBridgeman Apr 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Discussion

Suggested Execution Plan

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ckunki Apr 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ckunki left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

Rimsha2535 commented Mar 19, 2026 •

edited

Loading

ArBridgeman Apr 15, 2026 •

edited

Loading

ArBridgeman Apr 15, 2026 •

edited

Loading

ArBridgeman Apr 15, 2026 •

edited

Loading

ArBridgeman Apr 15, 2026 •

edited

Loading

ArBridgeman commented Apr 15, 2026 •

edited

Loading

ArBridgeman Apr 15, 2026 •

edited

Loading

ckunki Apr 15, 2026 •

edited

Loading