Skip to content

Replace self-upgrade workflow with Renovate JSONata manager #636

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.

Sign up for GitHub

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

Open
erikgb wants to merge 1 commit into
base: main
Choose a base branch
from
+32 −129
Open

Replace self-upgrade workflow with Renovate JSONata manager #636

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 2 additions & 4 deletions modules/repository-base/01_mod.mk
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -24,13 +24,11 @@ repository_base_dir := $(_repository_base_module_dir)base/
## @category [shared] Generate/ Verify
generate-base:
cp -r $(repository_base_dir)/. ./
cd $(repository_base_dir) && \
find . -type f | while read file; do \
sed "s|{{REPLACE:GH-REPOSITORY}}|$(repo_name:github.com/%=%)|g" "$$file" > "$(CURDIR)/$$file"; \
done
if [ ! -e ./.github/renovate.json5 ]; then \
mkdir -p ./.github; \
cp $(_repository_base_module_dir)/renovate-bootstrap-config.json5 ./.github/renovate.json5; \
fi
# TODO: Remove when all downstream repos are updated
rm -f ./.github/chainguard/make-self-upgrade.sts.yaml ./.github/workflows/make-self-upgrade.yaml

shared_generate_targets += generate-base
10 changes: 0 additions & 10 deletions modules/repository-base/base/.github/chainguard/make-self-upgrade.sts.yaml
View file
Open in desktop

This file was deleted.

114 changes: 0 additions & 114 deletions modules/repository-base/base/.github/workflows/make-self-upgrade.yaml
View file
Open in desktop

This file was deleted.

31 changes: 30 additions & 1 deletion renovate-config.json5
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,37 @@
extends: [
'github>cert-manager/renovate-config:default.json5',
],
"customManagers": [

@SgtCoDFish SgtCoDFish Jun 12, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion(claude): Found by AI, edited by me. I've not dug into checking if this is legit, so I'm not going to consider it a blocker or anything - but if you think it's legit + worth fixing, I'm happy to re-review next week!

Missing executionMode: 'branch'

The new packageRules entry for custom.jsonata is missing executionMode: 'branch', which every other rule with postUpgradeTasks in the repo uses.

Without it, Renovate defaults to per-update mode, meaning the three make commands run once per updated module entry. For a typical klone.yaml with several modules all pinned to the same hash those commands would run 7 times on a single branch. With executionMode: 'branch', they run once for the whole branch.

@erikgb erikgb Jun 12, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, this is interesting. I am going to POC this in the helm-tool project.

@erikgb erikgb Jun 12, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cert-manager/helm-tool#279

@erikgb erikgb Jun 12, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, this works, and I have updated the PR to include executionMode: 'branch'.

{
"customType": "jsonata",
"fileFormat": "yaml",
"managerFilePatterns": ["klone.yaml"],
"matchStrings": [
'targets.*.{\
"datasource": "git-refs",\
"versioning": "git",\
"depName": folder_name,\
"packageName": repo_url,\
"currentValue": repo_ref,\
"currentDigest": repo_hash\
}',
]
}
],
packageRules: [
{
"groupName": 'Makefile Modules',
"matchManagers": ["custom.jsonata"],
"matchFileNames": ["klone.yaml"],
"postUpgradeTasks": {
"commands": [
"make vendor-go",
"make generate-klone",
"make generate"
Comment on lines +30 to +32

@SgtCoDFish SgtCoDFish Jun 10, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

note: I think there's something interesting here I'd not thought enough about before.

vendor-go is in the tools module and generate-klone is in the klone module. generate is a target built from several modules. In this PR we're changing the repository-base module.

I think the implication is that to use this self upgrade flow (maybe to use makefile modules at all?) you need at least the repository-base, tools and klone modules.

Makes me think that our separation of modules isn't quite right - we have really important cross dependencies across these three core modules. I wonder if it would make sense to condense these modules down into a single base module, conceptually.

(Not a blocker or anything because this is only for our consumption and we use those modules everywhere anyway - I'm just thinking out loud)

@SgtCoDFish SgtCoDFish Jun 10, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is actually a meaningful implication of this - the make-self-upgrade GH action used the setup-go action to provision go, so the repository-base + klone modules were all that were required for self-upgrades. Now in this PR we add a (hard) dependency on the tools module because we're using make vendor-go instead.

I don't think that's a blocker either, but it's worth calling out.

@erikgb erikgb Jun 10, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point! Do we really need to have an exact Go version when running make generate-klone and make generate? Or would it be sufficient to have a Go version newer than version X?

@erikgb erikgb Jun 10, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had another look, and while I agree on your problem statement about module separation, I think this could be fixed in a follow-up PR I'll vote in favour of moving the vendor-go and unvendor-go targets to the repository-base module. And also merge the klone module into the repository-base module. WDYT, @inteon?

But in the context of this PR, I propose to keep it as proposed. I just tested this PR in the website project, which is our project with less Go content, and it works.

],
"executionMode": "branch",
}
},
{
matchFileNames: [
'**/go.mod',
Expand All @@ -22,6 +52,5 @@
// Exclude files that are sourced from makefile-modules and shouldn't be upgraded in projects using makefile-modules.
'make/_shared/**',
'.github/workflows/govulncheck.yaml',
'.github/workflows/make-self-upgrade.yaml',
],
}
Loading