-
Notifications
You must be signed in to change notification settings - Fork 93
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
feat: Adding stack with minimal Devfile that only contains metadata fields and the schema version #118
Conversation
…ields and the schema version Signed-off-by: Ilya Buziuk <ibuziuk@redhat.com>
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: ibuziuk The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Would this stack be ever useful for someone? |
This is not meant to be a hack by any means, but rather the most minimal devfile anyone could start with. The analogy could be docker scratch - https://hub.docker.com/_/scratch |
@@ -0,0 +1,7 @@ | |||
schemaVersion: 2.2.0 | |||
metadata: | |||
name: empty |
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.
might be better to name it as scratch to use the common analogy in the container world with https://hub.docker.com/_/scratch
This is a good analogy. Similar to a scratch container, this just on its own is not useful for anything. But it is a good starting point for building on top of it. That is why I don't think that this should be in a devfile registry together with other devfile stacks.
Devfile is, by its own definition, complex and hard to start with, and I'm afraid that in its current form, it always will be. Devfile is just a big complex structure. The approach to address this should be that we try to create a good set of devfile stacks that can be used out-of-the box for most of the projects. The only time user would need to touch devfile.yaml directly is if the users' project has something non-standard, unique, or specific to only their project. |
/uncc |
@ibuziuk: The following tests failed, say
Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
This PR has been open for almost 2 years now and will close for now, feel free to re-open if you'd like to resume effort on this contribution. cc @devfile/devfile-services-team @ibuziuk |
Signed-off-by: Ilya Buziuk ibuziuk@redhat.com
What does this PR do?:
Adding stack with minimal Devfile that only contains metadata fields and the schema version.
For Eclipse Che / Dev Spaces that devfile can be used for starting a workspace without any projects cloned.
Which issue(s) this PR fixes:
Related to eclipse-che/che#21554
PR acceptance criteria:
Have you read the devfile registry contributing guide and followed its instructions?
Does this repository's tests pass with your changes?
Does any documentation need to be updated with your changes?
Have you tested the changes with existing tools, i.e. Odo, Che, Console? (See devfile registry contributing guide on how to test changes)
How to test changes / Special notes to the reviewer:
The build is currently failing with
Error: failed to generate index struct: /build/stacks/empty devfile is not valid: [metadata.language is not set metadata.projectType is not set]
but the question is do we really want to enforce the language and the projectType ?