Skip to content

Add docs for extraDevfileEntries.yaml #445

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.

Sign up for GitHub

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

Merged
merged 1 commit into from
May 10, 2021
Merged

Add docs for extraDevfileEntries.yaml #445

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
30 changes: 30 additions & 0 deletions docs/proposals/registry/registry-structure.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -36,6 +36,36 @@ The following requirements are imposed on the devfile registry repository:
2) Each devfile stack folder must contain a `devfile.yaml`. Other files such as vsx plugins, stack logos, etc. can be included as needed.
3) Any build tools for the registry (such as scripts or Dockerfiles) should not be located at the top-level of the stack, and should reside in their own folder.

Optional file to support stacks/samples from other repositories:

A file called `extraDevfileEntries.yaml` can be added under the root of the devfile registry source repository to add samples and stacks from other repositories to the registry. This file contains the location information on where the extra samples and stacks can be found.

Sample `extraDevfileEntries.yaml`:
```
schemaVersion: 1.0.0
samples:
- name: nodejs-basic
displayName: Basic NodeJS
description: A simple Hello World application
icon: nodejsIcon.svg
tags: ["NodeJS", "Express"]
projectType: nodejs
language: nodejs
git:
remotes:
origin: https://github.com/redhat-developer/devfile-sample
Comment on lines +54 to +56
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Loooks good to me, except maybe one ques that pops into my head

what is the expected outcome(index) if git has multiple remotes.

git:
    remotes:
        origin: https://github.com/redhat-developer/devfile-sample
        my-fork: https://github.com/my-repo/devfile-sample

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The struct of remotes is a map

type Git struct {
	Remotes map[string]string `yaml:"remotes,omitempty" json:"remotes,omitempty"`
}

which means it is a map with multiple entries if the git has multiple remotes, so it's similar to your example above

Copy link
Member

@maysunfaisal maysunfaisal May 5, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand, but what is the expected index.. Will we have two index entries pointing to both the remote repositories? How does registry-support know which repo to choose in this case to point the sample/stack 🤔

The devfile/api schema has a checkoutFrom.remote to mention which remote if the length of remotes map is greater than 1:

Screen Shot 2021-05-05 at 2 12 34 PM

Copy link
Contributor Author

@GeekArthur GeekArthur May 6, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For samples and stacks from other repos (resources not store in the registry), we only display the metadata to consumers from the index and they decide how to use them. Also I rethink this, given the git field is only for samples and stacks from other repos , then the relationship should be one specific sample/stack per specific repo, it's different from one generic stack contains multiple starter projects and multiple repos.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For sample projects, I don't think it should have multiple remote (same reason as starterProjects). Both samples and starterProjects are only being cloned one and then it gets detached from the original, i.e. no git remote is setup. Therefore, it doesn't make sense to have multiple remotes. We should restrict that use case.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To restrict it, I think we add it as part of the validation code in the index generator.

- name: vertx-secured-http
displayName: Vert.x with secured HTTP
description: A Vert.x application using secured HTTP
icon: vertxIcon.svg
tags: ["Java", "Vert.x"]
projectType: vertx
language: java
git:
remotes:
origin: https://github.com/openshift-vertx-examples/vertx-secured-http-example-redhat
```

### Layer Media types
Currently, when we push devfile stacks to an OCI registry, it's pushed as a single layer, using the `application/vnd.devfileio.devfile.layer.v2+yaml` media type. We should instead be pushing the stack as a multi-layer artifact, adding the additional layers:

Expand Down