add dependency-update workflow template (fixes #683)

[Rimsha2535]

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]

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

[ArBridgeman]

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:

1. 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>

2. 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]

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.

[ArBridgeman]

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]

When we add the slack step to the dependency-update.yml, we should include Python in the title, so it's easy to search in the slack channel.

[ArBridgeman]

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:

1. ✅ No vulnerability detected, so no update
   https://github.com/exasol/python-toolbox/actions/runs/24443525540/job/71414050584
2. ✅ 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]

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

1. 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.')

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

• Create branch
• Commit changes & push
• Create pull request

[ckunki]

Added 2 comments

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud