How to keep my own custom image based on finpilot in sync with the finpilot development

[manfredlotz]

Months ago I created my own custom image by using https://github.com/projectbluefin/finpilot where I clicked on Use this template to create a new repository in github. This works all fine till today.

The finpilot repository gets developed further. I can see changes in Containerfile and build directoryy aso.

The state of my (per template) created repository stays the same. How can I participate from the further development of finpilot?

[dosubot[bot]]

Finpilot doesn't currently document a workflow for syncing structural template changes (Containerfile, build scripts, etc.) back into repos created with "Use this template." Renovate handles dependency and GitHub Actions version bumps automatically, but it won't catch changes to the Containerfile or build/ directory structure [1] [2].

Since GitHub's "Use this template" creates a completely independent repo with no git relationship to finpilot, you'll need to manually pull in upstream changes. The cleanest approach:

1. Add finpilot as a remote:

   cd your-repo
   git remote add finpilot https://github.com/projectbluefin/finpilot.git
   git fetch finpilot

2. Merge or cherry-pick the changes you want:

   # Option A: merge everything (may have conflicts with your customizations)
   git merge finpilot/main --allow-unrelated-histories
   
   # Option B: cherry-pick specific commits
   git log finpilot/main --oneline  # find the commits you want
   git cherry-pick <commit-hash>

3. Resolve any conflicts, especially in Containerfile and your customized build scripts, then push via a PR so CI validates everything.

Going forward, you could periodically git fetch finpilot and diff against your branch to see what's new. This is a general Git workflow — finpilot itself doesn't provide tooling for this (yet).

For more on finpilot's build architecture and maintenance: https://docs.projectbluefin.io

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[alexliluz]

A repository created with Use this template does not stay content-linked to the template. GitHub documents that it starts with a single commit and has an unrelated history, unlike a fork. The template_repository metadata records the source, but it is not an update channel.

I checked the public manfredlotz/bluefin-dx-nvidia-open-ml repository rather than guessing its template age:

• its initial commit is e7ad05f, with tree e4d8277;
• that tree exactly matches finpilot commit f2240c52;
• from f2240c52 to current finpilot/main, the template changed 68 files, including replacement of the build workflow and large changes to Containerfile, Justfile, build/, validation, and maintenance docs;
• a three-way check of that whole delta against the customized repository conflicts in the build workflow, Containerfile, Justfile, artifacthub-repo.yml, build/10-build.sh, and other customized files.

So I would not use git merge finpilot/main --allow-unrelated-histories as the default here. It combines two unrelated project histories and turns a template migration into one very large merge.

There are two different update channels:

1. Moving dependencies: keep Renovate enabled. Finpilot's maintenance guide says it updates OCI digests, GitHub Actions SHAs, and pinned tool versions.
2. Template structure/build logic: review and port these deliberately through a PR. Renovate cannot synchronize arbitrary Containerfile, workflow, or build/ changes.

For this repository, the exact review commands are:

git remote add finpilot https://github.com/projectbluefin/finpilot.git
git fetch finpilot main
git switch -c chore/review-finpilot-sync

# Everything the template changed since this repo's exact starting snapshot
git diff --stat f2240c52b1c188a52009fe0d1dffefefd8e86d2a finpilot/main
git diff --name-status f2240c52b1c188a52009fe0d1dffefefd8e86d2a finpilot/main

# Inspect the high-risk areas separately
git diff f2240c52b1c188a52009fe0d1dffefefd8e86d2a finpilot/main -- \
  Containerfile Justfile build/ .github/workflows/ .github/renovate.json

# Downstream customizations that must be preserved
git diff --name-status e7ad05f9748e601b67c97f62d76c1448587e468f main

If the finpilot remote already exists, skip git remote add.

For a small upstream fix, inspect it with git show --stat <sha> and cherry-pick that focused commit with git cherry-pick -x <sha>, resolving and validating it in the PR. Do not blindly cherry-pick every Renovate commit or changes that switch the base image away from your intended Bluefin variant.

For the current amount of drift, the lower-risk route is to generate a temporary repository from today's finpilot, reapply the downstream customizations shown by the last diff, and run the full build/validation loop. Only migrate the production repository after that clean-template version builds successfully. This gives a readable review of “new template + our customizations” instead of a 68-file unrelated-history merge.

Going forward, record the last reviewed finpilot commit in something like UPSTREAM.md. The next review then becomes git diff <recorded-sha> finpilot/main, which is repeatable and auditable.

References:

• GitHub template repositories (single initial commit and unrelated history): https://docs.github.com/en/repositories/creating-and-managing-repositories/creating-a-repository-from-a-template
• Finpilot maintenance guidance: https://github.com/projectbluefin/finpilot/blob/main/.agents/skills/finpilot-maintain.md

[manfredlotz]

@alexliluz Thanks a lot for your very helpful reply! Will look into this thoroughly.

[castrojo]

Ok I'm onboarding finpilot right into the factory. File everything you want as issues in the finpilot repo. Then whenever enough people say it's a good idea, you all add it to the clanker-queue. And then our own agents can maintain the thing for us.

And I say this because if you're a custom image builder we want to do what I'm doing in fsdk-containers, you can just have the magical buildstream amazingness. You will never need another distrobox again you'll just have the perfect thing.

Anyway the updates are landing in the repo soon and it'll be clearer to your agents on how to use it. If you are using this thing tell me and I'll add you to the triage group this could be cool. Then you all just do design work in plans and farm out to the agents.