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.