feat: self healing dependabot updates

[mfranzke]

Proposed changes

On prettier and stylelint dependency updates the codestyles might have changed so that the pipelines would initially fail and someone would need to run those linter/code formatters to transform the codebase to the new codestyles. Instead of doing this manually it would be nice to have a "self-healing" pipeline.

The only remaining step at the moment would be to retrigger the pipeline again, as GitHub wouldn't allow a pipeline run to get triggered after the pipeline has commited changed code (like in this case).

ChatGPTs answer on why the pipeline wouldn't run after a commit by the pipeline itself

You're running into a known and nuanced behavior of GitHub Actions.

✅ Summary of the Issue

When you push a commit to a Pull Request branch from within a GitHub Actions workflow, GitHub cancels the current workflow (as expected) and starts a new one, but sometimes the new one does not run any jobs and just says:

"There are no checks for this commit"

This happens especially when:

• The workflow is modifying and committing to the same branch it is running from.
• The commit is made with a bot token (e.g., GITHUB_TOKEN), not a real user PAT (Personal Access Token).
• The workflow uses default on: pull_request or on: push triggers.

---

🔍 Why It Happens

1. Workflow-trigger loop prevention
   GitHub has safety logic to prevent infinite CI loops. If a workflow pushes a commit back to the same branch (or PR) it's running from, GitHub may choose not to trigger a new workflow, especially if the commit came from a GitHub Action itself.

2. GITHUB_TOKEN behavior

   • Commits made using GITHUB_TOKEN don't trigger workflows on push or pull_request events unless explicitly configured.
   • This token is designed to avoid self-triggering behavior.

3. Triggering logic specifics

   • If the new commit doesn’t change any files that affect workflow conditions, or if the workflow file was modified but is now identical, GitHub may skip re-running the pipeline.
   • Also, if there is no on: push event configured, and you're committing directly to a branch, nothing may run.

---

🛠 How to Fix It

✅ Option 1: Use a Personal Access Token (PAT)

Replace GITHUB_TOKEN with a PAT from a GitHub user with permission. This allows the commit to trigger workflows as if it were from a real developer.

- name: Commit and push changes
  run: |
    git config user.name "your-username"
    git config user.email "your-email@example.com"
    git add .
    git commit -m "Automated update"
    git push https://<username>:${{ secrets.PAT }}@github.com/owner/repo.git HEAD:branch

⚠️ Do not hardcode the token — use secrets.PAT.

✅ Option 2: Use workflow_run to chain jobs

If you want to chain workflows after a commit, use workflow_run to explicitly start a second workflow after the first completes.

✅ Option 3: Modify on: conditions

Ensure your workflow is triggered by both push and pull_request:

on:
  push:
    branches:
      - '**'
  pull_request:
    types: [opened, synchronize, reopened]

---

🔍 Optional: Debug with actions/github-script

Use actions/github-script to log what's happening with events and commits programmatically if needed.

---

✅ TL;DR

• Yes, GitHub Actions can make commits that trigger further workflows.
• But if you use GITHUB_TOKEN, GitHub suppresses those triggers by default to avoid loops.
• Use a Personal Access Token if you want those commits to start new workflows.
• Also ensure your workflows are listening for the right on: events.

Let me know if you want a code example or help setting up a PAT securely.

Additionally some problems wouldn't be auto-fixable (by prettier --write or stylelint --fix), those would still need to be done manually obviously.

I've successfully tested it with db-ui/base@e3efcf0

Types of changes

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Refactoring (fix on existing components or architectural decisions)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation Update (if none of the other choices apply)

Further comments

[github-actions]

🔭🐙🐈 Test this branch here: https://db-ux-design-system.github.io/core-web/review/feat-self-healing-dependabot-updates

[Copilot]

Pull Request Overview

This PR introduces a new self-healing pipeline for Dependabot updates related to Prettier and Stylelint so that code formatting issues are automatically fixed after dependency updates. The key changes include:

• Adding a new workflow (self-healing-dependabot-updates) in the pull-request pipeline.
• Implementing conditional steps to identify, format, commit, and push code changes based on the PR title.
• Configuring Node.js, dependency installation, and commit steps within the new workflow.

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
.github/workflows/pull-request.yml	Adds a new job to trigger the self-healing dependabot updates workflow.
.github/workflows/99-self-healing-dependabot-updates.yml	Implements the self-healing logic with formatting, commit, and push steps.

Comments suppressed due to low confidence (1)

.github/workflows/99-self-healing-dependabot-updates.yml:59

• [nitpick] The commit message 'refactor(test): auto-format codebase' may be confusing since the update only performs code formatting. Consider revising the commit message to better reflect that it's an auto-format commit.

git commit --all -m "refactor(test): auto-format codebase" || echo "No changes to commit"

[Copilot]

Pull Request Overview

This PR adds an automated self-healing mechanism to handle formatting updates triggered by dependabot PRs for stylelint and prettier. Key changes include updating the stylelint linting pattern in package.json, integrating a new job into pull-request.yml, and adding a dedicated workflow to auto-format updated code.

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
package.json	Updates lint:stylelint command to target both CSS and SCSS files.
.github/workflows/pull-request.yml	Introduces a self-healing dependabot updates job in the PR pipeline.
.github/workflows/99-self-healing-dependabot-updates.yml	Adds a workflow to auto-format code using stylelint and prettier on PRs.

Comments suppressed due to low confidence (1)

.github/workflows/99-self-healing-dependabot-updates.yml:60

• Consider using a more appropriate commit type (e.g., 'chore') instead of 'refactor(test)' for auto-format commits, as it may be misleading about the nature of the changes.

git commit --all -m "refactor(test): auto-format codebase" || echo "No changes to commit"

[nmerget]

I think it makes sense to move the part below into a custom action to use it for every auto-commit in our repo.

It would be an additional advantage because you could use the if: env.stylelint_update == 'true' || env.prettier_update == 'true' once. Would you like to do it or should I help you?

[mfranzke]

@nmerget I like this idea, and the latter, please.

[nmerget]

@mfranzke I would keep this always inside the pipeline. We don't like to uncommet/comment it every time we debug.

[mfranzke]

It was a comment by GitHub Copilot that sharing the full content of this variable might leak internal information. As the logs are public, this might be a valid aspect. Is there a non-public-space we could pass the output to ?

[nmerget]

To fix the issue, we will:

1. Assign the value of github.head_ref to an intermediate environment variable.
2. Use the environment variable in the shell command with native shell syntax (e.g., $VAR) instead of direct interpolation (${{ ... }}).
3. This approach ensures that the value is treated as a literal string by the shell, preventing command injection.

The changes will be made in the .github/actions/auto-commit/action.yml file, specifically in the step where gh pr create is executed.

---