Closed hany closed 2 months ago
Actually, I'm working on that one using https://github.com/buildpacks-community/kpack as an option.
The Kubero "buildpack" naming is misleading. This will be the first thing to change.
Actually, I'm working on that one using https://github.com/buildpacks-community/kpack as an option.
The Kubero "buildpack" naming is misleading. This will be the first thing to change.
That's great! Is there a place where we can follow your progress on this one?
@hany I've just started to work on this topic for version 2.4.0
I did manage to build and push an image with kpacks. However, there is still an issue on how to handle the finished build. There for I plan to create a separate job to handle that. This is managed in a separate image and repository.
Kubero will get a whole new CRD (api) to handle builds. This has a lot of benefits. It will be possible to store build logs, list all builds, and reset to an older build.
Kubero Runbuilds won't be affected and keep working as usual. But I tend to focus kubero on image building.
Next step was to cleanup the registry configuration and prepare it for kpacks https://github.com/kubero-dev/kubero-operator/commit/69ab305d54d35a201d00c9ae72fd45e2a52b5d9d
closed by accident with the merge
I'm still working on this topic and making progress. The Operator is mostly done. UI needs some more improvements.
I am currently struggling with building with kpacks on my local installation.
Quite a time since my last update.
Still working almost daily on this topic.
Here is my latestes WIP
Making some more progress... added state, activity and duration
So ... final progress made today. Refactored all the kpack stuff for native buildpack support.
Finally done
Description
I understand that the use of the term "buildpacks" used by Kubero is not the same as the concepts Cloud Native Buildpacks.io (CNB) brings. We've been using CNB's for some time, and appreciate its simplicity and auto-detection capabilities. It's quite flexible and configurable (for example, being able to specify versions of the languages used, or having it auto-detect the version based on standard files from the repo). For example, here are the various supported package management capabilities for Python-based apps:
https://paketo.io/docs/howto/python/#use-a-package-manager
Or auto-detection of Ruby versions:
https://paketo.io/docs/howto/ruby/#override-the-detected-ruby-version
Has there been any thoughts for adding or utilizing Buildpacks.io or Paketo? It may alleviate the need to maintain a repo for the various "buildpacks" and utilize a common framework.
Possible solution
Utilizing Buildpacks.io or Paketo.io for buildpacks instead of maintaining a Kubero Buildpacks Repo.
Alternatives
No response
Additional information
No response