Stack vs sample proposal and outer loop #474
Conversation
elsony
requested review from
amisevsk,
davidfestal and
sleshchenko
as code owners
elsony
changed the title
|
|
||
| `buildContext`: Path of source directory to establish build context. Default to ${PROJECT_ROOT} (optional) | ||
|
|
||
| `location`: Dockerfile location which can be an URL or a path relative to buildContext |
There was a problem hiding this comment.
Should this default to Dockerfile to replicate the semantics of docker build ${buildContext}?
There was a problem hiding this comment.
When running docker build command, it either uses the current working directory or the build context specified when running the command. When tools are trying to execute the dockerfile, we need to define the default directory that the tools can run the docker build command. With the described behaviour, it means the tools can find the Dockerfile in the project root by default which is the most common setup of the project root.
|
|
||
| __Note:__ | ||
| 1. A common pattern will be using a global variable to define the image name (`myimage` in the example above) so that it can be easily referred to in the deploy step later. | ||
| 2. The `apply` command with the `image` component is optional. If the `apply` command that references an image component does not exist, then the image build will be done at the startup automatically (similar to the behaviour of the existing `kubernetes` components). If there is an `apply` command that references the `image` component, then the user will need to create a composite command to chain the image build apply command with the deploy command (see the deployment command section) to complete the build and deploy. |
There was a problem hiding this comment.
Which apply command is this referring to?
| 1. A common pattern will be using a global variable to define the image name (`myimage` in the example above) so that it can be easily referred to in the deploy step later. | ||
| 2. The `apply` command with the `image` component is optional. If the `apply` command that references an image component does not exist, then the image build will be done at the startup automatically (similar to the behaviour of the existing `kubernetes` components). If there is an `apply` command that references the `image` component, then the user will need to create a composite command to chain the image build apply command with the deploy command (see the deployment command section) to complete the build and deploy. | ||
|
|
||
| ### Example using a file Dockerfile with registry and secret for the image push: |
There was a problem hiding this comment.
| ### Example using a file Dockerfile with registry and secret for the image push: | |
| ### Example using a Dockerfile with registry and secret for the image push: |
| - name: mydockerfileimage | ||
| image: | ||
| imageName: {{myimage}} |
There was a problem hiding this comment.
| - name: mydockerfileimage | |
| image: | |
| imageName: {{myimage}} | |
| - name: mydockerfileimage | |
| image: | |
| imageName: {{myimage}} |
| - name: mydockerfileimage | ||
| image: | ||
| imageName: {{myimage}} | ||
| dockerfile: | ||
| git: | ||
| remotes: |
There was a problem hiding this comment.
| - name: mydockerfileimage | |
| image: | |
| imageName: {{myimage}} | |
| dockerfile: | |
| git: | |
| remotes: | |
| - name: mydockerfileimage | |
| image: | |
| imageName: {{myimage}} | |
| dockerfile: | |
| git: | |
| remotes: |
| location: Dockerfile | ||
| args: [ ] | ||
|
|
||
| The git definition will be the same as the one in `starterProjects` definition that supports `checkoutFrom` |
There was a problem hiding this comment.
Can we just reuse projects/starterProjects here?
There was a problem hiding this comment.
We are just sharing the git definition with starterProjects/projects. This section is not related to starter project so it does not apply.
|
|
||
| The git definition will be the same as the one in `starterProjects` definition that supports `checkoutFrom` | ||
|
|
||
| `location`: the location of the dockerfile within the repo. If `checkoutFrom` is being used, the location will be relative to the `checkoutFrom`. |
There was a problem hiding this comment.
This seems unclear to me -- checkoutFrom refers to a remote, so what does "relative" mean in this context?
| labels: | ||
| app: {{.COMPONENT_NAME}} | ||
| spec: | ||
| containers: |
There was a problem hiding this comment.
Could you fix the indentation errors throughout -- I don't know if it's a misplaced tab character or something.
|
|
||
| ## Overview | ||
|
|
||
| The existing devfile registry focuses on the stack support to provide generic language/framework/runtime, e.g. Node, Java maven, Quarkus, etc., support to build and run user applications. These devfiles are called ___*stack devfiles*___. There is another kind of devfile in a devfile registry that is tailored for a building and running a specific application. These devfiles are referred to as ___*sample devfiles*___ (example: https://github.com/redhat-developer/devfile-sample). |
There was a problem hiding this comment.
I think e.g. ***sample devfiles*** looks more markdown-y and renders the same as ___*sample devfiles*___
|
|
||
|
|
||
|
|
||
|
|
There was a problem hiding this comment.
Trim trailing blank lines
|
|
||
| Alternatively, if we assume the devfile contained in the sample folder may refer to the original stack instead of the specific example, we may need to include a way for the user to specify the metadata associated with the sample as part of the sample definition. | ||
|
|
||
| schemaVersion: 1.0.0 |
There was a problem hiding this comment.
It would be better we use our current extraDevfileEntries.yaml in the registry resource repo as example:
schemaVersion: 1.0.0
samples:
- name: nodejs-basic
displayName: Basic NodeJS
description: A simple Hello World Node.js application
icon: https://github.com/maysunfaisal/node-bulletin-board-2/blob/main/nodejs-icon.png
tags: ["NodeJS", "Express"]
projectType: nodejs
language: nodejs
git:
remotes:
origin: https://github.com/redhat-developer/devfile-sample.git
- name: code-with-quarkus
displayName: Basic Quarkus
description: A simple Hello World Java application using Quarkus
icon: .devfile/icon/quarkus.png
tags: ["Java", "Quarkus"]
projectType: quarkus
language: java
git:
remotes:
origin: https://github.com/elsony/devfile-sample-code-with-quarkus.git
- name: java-springboot-basic
displayName: Basic Spring Boot
description: A simple Hello World Java Spring Boot application using Maven
icon: .devfile/icon/spring-logo.png
tags: ["Java", "Spring"]
projectType: springboot
language: java
git:
remotes:
origin: https://github.com/elsony/devfile-sample-java-springboot-basic.git
- name: python-basic
displayName: Basic Python
description: A simple Hello World application using Python
icon: .devfile/icon/python.png
tags: ["Python"]
projectType: python
language: python
git:
remotes:
origin: https://github.com/elsony/devfile-sample-python-basic.git
| } | ||
| ] | ||
|
|
||
| The bold entries highlighted the differences between a stack entry vs a sample entry in the devfile index registry. |
There was a problem hiding this comment.
The bold entries are not displayed after moving docs from google docs, we need manually added them again by using markdown.
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: elsony 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 |
Signed-off-by: eyuen eyuen@redhat.com
What does this PR do?
Move design doc from gdoc (https://docs.google.com/document/d/1tbzZK9aWtpw5AtoZmUl1Jy8x8w9N5hhjXu3c26VYiYY/edit?usp=sharing and https://docs.google.com/document/d/1SL3ZJyAy8lp973EzQpY36VjTJHoyGXl2zUXokPiXwK8/edit?usp=sharing) to design doc in repo for public access.
What issues does this PR fix or reference?
Design doc for #279 and #346
Is your PR tested? Consider putting some instruction how to test your changes
Design doc changes only
Docs PR
Design doc changes only