Comments (10)
Since I started using the imgpkg
I feel like we are missing a init command to help bootstrap a bundle. I do have some questions:
- If the user does not provide metadata for the bundle should we create the
bundle.yml
file? - If the user provides some metadata what is the minimum information we would require to create a
bundle.yml
file? - Not a fan of creating a dependency between
imgpkg
andkbld
. Neverthelessimgpkg
does not have a way to pre-populate theimages.yml
file. What if we asked the user to provide the file something likeimgpkg init -f my/configuration/files --image-lock /images/i/want/in/my/bundle/images.yml
? If the user did not provide the file we would create the.imgpkg/images.yml
file with just the skeleton.
from imgpkg.
To maybe repurpose/simplify, the original design docs call for initializing a bundle directory (i.e. .imgpkg
).
If the user does not provide metadata for the bundle should we create the bundle.yml file?
If the user provides some metadata what is the minimum information we would require to create a bundle.yml file?
Not sure if populating that directory with empty files like the bundle metadata would be valuable to end users. In thinking this over a bit more, there needs to be more discussion on use cases for the bundle metadata file before it becomes a core part of an imgpkg
command.
What if we asked the user to provide the file something like imgpkg init -f my/configuration/files --image-lock /images/i/want/in/my/bundle/images.yml?
I think this approach would be great, but there is the design question of how kbld
already provides this behavior. I agree that adding a dependency between kbld and imgpkg is a not great pattern.
What might be best is to close this issue and turn it into a discussion first, or try to better understand what the original intent was behind what is documented in the original proposal.
from imgpkg.
imgpkg init -f my/configuration/files --image-lock /images/i/want/in/my/bundle/images.yml
At this point, we may as well just add the ability for push to generate the imgpkg dir for you if you specify an images lock, instead of making this a whole new command.
The initial intent of init was to set up a space on disk that is an empty bundle, sort of like git init. It would not create nor push a bundle. This would give the user the correct directory structure with empty metadata files (BundleLock and ImageLock) that they can fill in however they want, or leave empty if they just want to satisfy push's requirements. It would save the user the effort to create the directory, fill it in with properly structured yaml, etc
Tangentially, I wonder if supporting something like a .imgpkgignore on push would make sense. Then users could do something like:
- imgpkg init
- create vendir file
- vendir sync
- kbld for lock files if needed
- then imgpkg push (with vendir files in .imgpkgignore if they dont want to include them)
from imgpkg.
@ewrenn8 I like the workflow that you are suggesting, where init would just create the folder structure and eventually the images.yml empty or we could provide a flag that would point to a file that contains the images lock file and we would just copy it into place. something like this:
imgpkg init --images-lock /tmp/images.yml
The Idea of an ignore is also interesting and can be an addon that we could provide to this init command in time.
@danielhelfand as per your point I think that we should bring this up in our community meeting so that we can come to a consensus.
from imgpkg.
Was thinking about this a bit more and am wondering if some type of plugin model might make sense for an imgpkg init
command. This would allow a user to specify what tool to use or a script in order to generate the ImagesLock and also create the .imgpkg
directory.
Through an env variable or through something via the imgpkg init
command, a user could specify what to shell out to when generating the lock file:
export IMGPKG_INIT=kbkd
imgpkg init -f manifests/
imgpkg init -f manifests/ --lock-generator kbld
from imgpkg.
The generator is an interesting idea, nevertheless, this would require imgpkg
to understand how to call kbld
to generate this lock file, and in the future when we would like to introduce a new lock generator we would have to add some specific logic for it. This is not unheard of since we do something very similar with kbld
.
from imgpkg.
This issue is being marked as stale due to a long period of inactivity and will be closed in 5 days if there is no response.
from imgpkg.
This seems like a viable idea that is in the midst of discussion: adjusted labels accordingly.
from imgpkg.
I am going to accept this issue. For now, I think we should start with the --lock-generator
flag and the implementation needed to use kbld
as the first generator.
Notes:
kbld
should not be embedded inimgpkg
(imgpkg
should call thekbld
binary to do the work)- Do we need to provide a path where we want to initialize the bundle? something like
imgpkg init -f manifests -o . --lock-generator kbld
?
from imgpkg.
Introduce the imgpkg init
command
As a user, I want to be able to bootstrap the process of pushing a bundle by using the init command.
The imgpkg init -f
command will generate an .imgpkg
directory in the provided directory. This .imgpkg
dir will contain and ImagesLock file filled with empty values for the images. Besides the -f
flag, which denotes the root of the bundle, the one optional flag for the imgpkg init
command is --lock-generator
, which specifies the generation of the ImagesLock file.
🟢 Scenario 1: imgpkg init -f
As an imgpkg user wanting to prepare and push a bundle, when I run imgpkg init -f .
,
I want imgpkg to create and check the minimum requirements to make my configuration in the current directory a bundle,
So that when I list all files in the current directory (ls -a .
), I see an .imgpkg/images.yml
file with no listed images.
🟢 Scenario 2: imgpkg init -f <> --lock-generator kbld
As an imgpkg user wanting to prepare and push a bundle with an images lock file, when I run imgpkg init -f staging-app --lock-generator kbld
,
I want imgpkg to create an ImagesLock file using the files provided via -f
and the kbld binary (provided by the user),
And create/check the minimum requirements to make my configuration a bundle,
So that when I list all files in the "staging-app" directory (ls -a staging-app
), I see an .imgpkg/images.yml
file with all dependent images detected by kbld.
🛑 Scenario 3: imgpkg init -f <> --lock-generator anythingElse
As an imgpkg user trying to bootstrap pushing bundle with an images lock file, when I run imgpkg init -f . --lock-generator imgpkg
,
I want imgpkg to give an error, lightly explaining what a lock generator is and lists the options (just kbld at the moment)
So that when I try again, I know what lock generators I can use and how to use them.
Future considerations for this command:
- Add flags to populate/create fields in the bundle metadata file that may exist in the .imgpkg directory.
- Add the recognition of a
.imgpkgignore
file/dir that would also get created duringimgpkg init
from imgpkg.
Related Issues (20)
- Allow for file exclusions based on entries in an .imgpkgignore file - similar to .gitignore HOT 1
- Extra output and errors during shell completion HOT 3
- Allow directly pushing archives, in particular ZIP or JAR HOT 5
- imgpkg copy fails when copying images to dockerhub HOT 7
- Describe command no longer outputs yaml when tty is set to false
- multiple active keychain selection does not work
- imgpkg fails to pull images built using ko HOT 3
- Add the ability to check if a remote artifact is a bundle HOT 13
- Support OCI image layout HOT 3
- Release v0.34.0 HOT 1
- imgpkg tag list without the .imgpkg tags HOT 8
- In registry.go, newHTTPTransport function still uses workaround for windows for SystemCertPool utility
- Can't bundle Helm OCI artifacts HOT 4
- imgpkg Registry API does not honor secret provided via keychain
- Frequent calls to docker-credential-desktop and osascript when doing a copy HOT 8
- Content Length error when when retry happen on PUT HOT 2
- imgpkg copy between harbor projects fails with auth error HOT 2
- imgpkg removes group permissions when storing files in OCI image, which causes permission problems with the Jammy stack HOT 1
- Copy to tar and back to repository doesn't always work
- When resume happens while copying to tar a bundle with an index panic os thrown
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from imgpkg.