-
-
Notifications
You must be signed in to change notification settings - Fork 5
Added 'update-deps' skill and updated 'moby/docker' to 29.5.2. #383
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
+99
−1
Merged
Changes from all commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
213e6cc
Added 'update-deps' skill to bump Dockerfile dependencies.
AlexSkrypnyk e2d35b7
Reduced 'update-deps' skill scope to version check and edit only.
AlexSkrypnyk 9860f0a
Updated 'moby/docker' to 29.5.2.
AlexSkrypnyk 23c6c6b
Addressed code review: added language identifiers to fenced code bloc…
AlexSkrypnyk File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,94 @@ | ||
| --- | ||
| name: update-deps | ||
| description: Check the latest upstream version for every renovate-annotated dependency in the Dockerfile, then rewrite the pinned version literals in place. Use when the user asks to "update deps", "bump deps", "update dockerfile deps", or refresh image dependencies. Git operations are out of scope. | ||
| --- | ||
|
|
||
| # Update Dockerfile dependencies | ||
|
|
||
| Scan `Dockerfile`, resolve each renovate-annotated dependency's latest upstream version, and rewrite the pinned `version=...` literal in place. The skill stops after the file edits. Branching, committing, and PR creation are not part of this skill. | ||
|
|
||
| ## When to use | ||
|
|
||
| - User asks to update deps, bump deps, update dockerfile deps, or refresh image dependencies. | ||
|
|
||
| ## When NOT to use | ||
|
|
||
| - Updating Drupal / Composer / Vortex packages. Use the dedicated `/update-drupal`, `/update-vortex`, or Composer-related skills. | ||
| - Editing `versions-config.json` or `goss.yaml`. Both track runtime detection; neither pins versions. | ||
|
|
||
| ## Step 1 - Discover entries | ||
|
|
||
| Read `Dockerfile`. Find every block matching the Renovate custom-manager regex from `renovate.json`: | ||
|
|
||
| ```regex | ||
| #\s*renovate:\s*datasource=(?<datasource>\S+)\s+depName=(?<depName>\S+)(?:\s+versioning=(?<versioning>\S+))?(?:\s+extractVersion=(?<extractVersion>\S+))?\s*\n(?:.*\n)*?.*?(?:ENV|ARG|RUN)\s+.*?version=(?<currentValue>[^\s&]+) | ||
| ``` | ||
|
|
||
| For each match, record `{datasource, depName, versioning, extractVersion, currentValue, lineNumber}`. | ||
|
|
||
| Also capture the base image digest pin from the two `FROM` lines (builder + final): | ||
|
|
||
| - Pattern: `FROM php:8.4-cli-bookworm@sha256:<digest>` | ||
| - Datasource is `docker`. Both `FROM` lines must end up with the same new digest. | ||
|
|
||
| ## Step 2 - Resolve latest per datasource | ||
|
|
||
| Make one Bash call per command. Do not chain with `&&`, do not pipe with `|`; the global hook blocks both. If a step needs JSON processing, save the response to `.artifacts/tmp/` first, then run `jq` against the file in a separate call. | ||
|
|
||
| If any single resolver fails, record the dep as `error` and continue. Do not abort the whole run. | ||
|
|
||
| ### `github-releases` | ||
|
|
||
| 1. `gh api repos/<depName>/releases/latest --jq .tag_name` returns e.g. `v0.11.0`, `43`, or `docker-v29.5.2`. | ||
| 2. If the API returns 404 (no releases published, only tags), fall back to `gh api repos/<depName>/tags --jq ".[0].name"`. | ||
| 3. Normalize the tag to a bare version: strip any leading `v` and any non-semver prefix such as `docker-v` (moby/moby uses this). | ||
| 4. If `extractVersion` is something other than `^(?<version>.*)$`, apply that regex literally to the tag instead. | ||
|
|
||
| ### `npm` | ||
|
|
||
| 1. `npm view <depName> version` returns the latest semver, no prefix. | ||
|
|
||
| ### `node` (with `versioning=node`) | ||
|
|
||
| 1. `curl -fsSL https://nodejs.org/dist/index.json -o .artifacts/tmp/node-index.json` | ||
| 2. `jq -r 'map(select(.lts != false))[0].version' .artifacts/tmp/node-index.json` returns the latest LTS, e.g. `v24.15.0`. The filter is intentionally pipe-free. | ||
| 3. Strip the leading `v`. | ||
|
|
||
| ### `docker` (base image) | ||
|
|
||
| 1. `docker buildx imagetools inspect php:8.4-cli-bookworm --raw` prints the raw index JSON to stdout; redirect with `> .artifacts/tmp/php-index.json` is fine because it is a redirection, not a pipe. | ||
| 2. `jq -r ".manifests[0].digest" .artifacts/tmp/php-index.json` is one option, but the value the Dockerfile pins is the index digest, not a per-arch manifest digest. The simplest reliable command is `docker manifest inspect --verbose php:8.4-cli-bookworm` and read the top-level `Digest` field for the named tag. | ||
| 3. Fallback: `docker pull php:8.4-cli-bookworm`, then `docker inspect --format "{{index .RepoDigests 0}}" php:8.4-cli-bookworm`, then strip the `php@` prefix. | ||
|
|
||
| ## Step 3 - Print the diff | ||
|
|
||
| Render a markdown table so the user sees exactly what will change: | ||
|
|
||
| ```markdown | ||
| | Dependency | Datasource | Current | Latest | Status | | ||
| |-----------------|-----------------|-----------|-----------|------------| | ||
| | kcov | github-releases | 43 | 43 | up-to-date | | ||
| | docker (moby) | github-releases | 28.5.2 | 29.5.2 | bump | | ||
| | php (base) | docker | sha256:ca | sha256:7f | bump | | ||
| ``` | ||
|
|
||
| If nothing is behind, stop here and report "All dependencies are up to date.". Do not touch `Dockerfile`. | ||
|
|
||
| ## Step 4 - Edit the Dockerfile | ||
|
|
||
| For every `bump` row, use the `Edit` tool on `Dockerfile`: | ||
|
|
||
| - Include the preceding `# renovate: ...` comment line in `old_string` so the replacement is unambiguous when `version=<value>` is not unique on its own. | ||
| - Replace only the `<value>` after `version=`. Do not reformat surrounding lines. | ||
|
|
||
| For the base image bump, replace the `@sha256:<old>` substring with `@sha256:<new>` using `replace_all: true` (the digest substring is unique to the base image, so this safely covers both `FROM` lines). | ||
|
|
||
| After each edit, re-read the affected line to confirm the change landed correctly. | ||
|
|
||
| The skill ends here. Do not stage, commit, or push. | ||
|
|
||
| ## Notes | ||
|
|
||
| - `goss.yaml` and `versions-config.json` do not pin versions and are not touched. | ||
| - README's "Included packages" section is regenerated post-merge by `.github/workflows/update-readme.yml`. | ||
| - Yarn is intentionally pinned to v1.x (classic). `npm view yarn version` returns the latest 1.x; Yarn Berry is published as `@yarnpkg/cli`. |
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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,4 @@ | ||
| !.claude | ||
| !.claude/skills | ||
| !.claude/skills/* | ||
| .claude/settings.local.json | ||
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
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.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🧹 Nitpick | 🔵 Trivial | ⚡ Quick win
Simplify gitignore logic by removing redundant negation patterns.
The negation patterns (lines 1-3) attempt to explicitly include
.claude/skills, but Git tracks all files by default unless explicitly ignored. Negation patterns only make sense when negating a previous ignore rule. Since.claudeis not being ignored anywhere, these negation patterns are redundant and potentially confusing.If the intent is to track
.claude/skills/*while ignoringsettings.local.json, only line 4 is needed.♻️ Simplified approach
Alternatively, if you want to ignore everything in
.claude/except theskills/subdirectory:📝 Committable suggestion
🤖 Prompt for AI Agents
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not adopting. The negation patterns counteract a rule in the user's global ~/.gitignore that excludes .claude/ across all repos. Without these explicit un-ignores, the project-scoped Claude skill files in .claude/skills/ would be silently ignored. The negations look redundant when viewing only the project gitignore, but they are load-bearing once the global rule is in play.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@AlexSkrypnyk, understood — thank you for the explanation. That context makes the negation patterns completely sensible: they exist to override a global~/.gitignorerule that blanket-ignores.claude/across all repositories, ensuring the project-scoped skill files in.claude/skills/are still tracked. I'll record this so I don't flag it in future reviews.✏️ Learnings added