allow .devfile.yaml

[maxandersen]

(not sure if this is part of kubernets-api for devfile but it should for sure be part of the devfile spec - let me know if any better place this issue)

originally opened at redhat-developer/odo#3126 and redhat-developer/odo#3126

Simply asking that .devfile.yaml should be allowed for the name of the devfile to allow it to be hidden by default and not take up "visual space" in projects that create these files.

[sbose78]

Ack.

[metacosm]

@maxandersen you linked to the same 2 issues… 😄
That said, I'm ambivalent on this since I'm not sure the devfile should be hidden as it's potentially an integral part of the project.

[l0rd]

That's not strictly speaking something that will be transled in a change in the OpenAPI spec. And Che at least already allow .devfile.yaml if the file is specified explicitely but it doesn't automatically discover it (it discovers devfil.yaml).

But I agree that we may formalize that in the spec somehow: tools that supports the spec should automatically discover devfile.yaml and .devfile.yaml when a git repo or a local folder is provided.

[kadel]

But I agree that we may formalize that in the spec somehow: tools that supports the spec should automatically discover devfile.yaml and .devfile.yaml when a git repo or a local folder is provided.

If we formalize that than we need to also define that tools need to error out when both .devfile.yaml and devfile.yaml are present.

[l0rd]

if we formalize that than we need to also define that tools need to error out when both .devfile.yaml and devfile.yaml are present.

Right. Or define a precedence order.

[kadel]

Right. Or define a precedence order.

That will just lead to a lot of confusion

Let's say that I have a project that uses .devfile.yaml

• Someone doesn't notice that there already is .devfile.yaml and adds new devfile.yaml
• Now there are two devfiles and each might be different.
• If tooling just priorities devfile.yaml over .devfile.yaml the users that are used to editing .devfile.yaml will get confused about why their changes are not being reflected or vice versa.

This won't create a good user experience.
I think that erroring out in case of both devfile naming styles is present is the only way to make sure that there is no ambiguity or confusion.

[l0rd]

I think that erroring out in case of both devfile naming styles is present is the only way to make sure that there is no ambiguity or confusion.

You convinced me 👍

[maxandersen]

I would just print a warning rather than blocking users and error out.

But I'm fine either way.

[elsony]

@kadel How do you see odo create nodejs mynodename work with the existence of the .devfile.yaml in a project? We currently error out when the user has an devfile.yaml already exists in the project root. Do we error out with the existence of .devfile.yaml as well? Given that .devfile.yaml are not listed by default, will the user get confused on why component create failed in that case? Also, how do we handle odo create nodejs mynodename --downloadSource if the sample project contains a .devfile.yaml, do we skip copying the devfile.yaml from the stack in that case and just use .devfile.yaml?

[maxandersen]

Treat it the same as if you had a devfile.yml.

[gorkem]

I see a new PR on Che eclipse-che/che#17537

[rkratky]

@l0rd, what is the documentation tasks here (I see you added the area/documentation label)?

[l0rd]

@rkratky probably adding a paragraph about that in the devfile author guide

[elsony]

Based on the discussions, we'll support the .devfile.yaml. If both devfile.yaml and .devfile.yaml exists, then the tools will error out and let the user know that both files exist. We treat it as an error instead of a warning is to avoid any potential confusion on the user.

From the spec perspective, we'll:

1. add to the doc to specify this behaviour
2. check if the common library accepts a path (instead of including the devfile.yaml itself), then the parser will error out if both the devfile.yaml and .devfile.yaml exists at the specified path

[elsony]

@maysunfaisal pointed out that the existing devfile library does not currently have limitations on the devfile file name as long as it has the .yaml extension. I think it is fine to keep it that way to provide flexibility on the library code.

Having said that, we still need to make changes to support this on the registry library/registry build tools. We currently have to find the location of the devfile when building the index.jsp as part of scanning through the list of stacks. So the index.jsp build tools will need to look for either devfile.yaml or .devfile.yaml and flag as an error on the stack if both files are found in the registry as part of the index.jsp generation that is being run as part of the registry build tools.

@GeekArthur Can you make the change on the registry index generator code?

[GeekArthur]

@elsony Sure, I can do that.