allow .devfile.yaml

[maxandersen]

devfile.yaml is not really something you want to have listed in your project explorer or listed in directory constantly.

Would be great if che would look for .devfile.yaml if devfile.yaml is not found.

[maxandersen]

@ibuziuk i tried have a quick look and I can't find where che searches for devfile...can you give a pointer ?

[sunix]

@maxandersen maybe here https://github.com/eclipse/che/blob/8c2be9a8f4aa16377d430e141bd30ca62aad4ede/wsmaster/che-core-api-factory/src/main/java/org/eclipse/che/api/factory/server/urlfactory/URLFactoryBuilder.java#L107

[sunix]

https://github.com/eclipse/che/blob/8c2be9a8f4aa16377d430e141bd30ca62aad4ede/wsmaster/che-core-api-factory-github/src/main/java/org/eclipse/che/api/factory/server/github/GithubURLParser.java#L96

[maxandersen]

does not look like .withDevfileFilename() allows setting multiple possible locations.

But if we add a fallback at https://github.com/eclipse/che/blob/8c2be9a8f4aa16377d430e141bd30ca62aad4ede/wsmaster/che-core-api-factory/src/main/java/org/eclipse/che/api/factory/server/urlfactory/URLFactoryBuilder.java#L117
which looks for same path but with a "." at the front it could work from any URL import.

[skabashnyuk]

if @l0rd don't mind I think we can take this task to the next sprint. We need to agree on the order of the search. Is this correct order correct, any addition?

• devfile.yaml
• .devfile.yaml

[l0rd]

Yes let's take this for next sprint, I think we owe it to @maxandersen

[gorkem]

Let this dot be known as the maxandersen dot from this day forth. :)

[kadel]

What if both .devfile.yaml and devfile.yaml is present?
Based on the discussion it looks like that .devfile.yaml will get silently ignored and devfile.yaml will be used. It might not be a common situation but it could happen by mistake and then it will get quite confusing for users.

I don't think that it is a bad thing to have a devfile file always visible.

[sunix]

@kadel at least we give the choice to the project team which files it wish to work with .devfile.yaml or devfile.yaml.
If that situation is happening, i guess someone in the team would fix it eventually... it is not a big deal in my opinion.

[kadel]

How about at least showing a warning when there are both devfile.yaml and .devfile.yaml?

@maxandersen Why it is a problem when devfile.yaml shows up in the file explorer?

[JPinkney]

Isn't this something you could technically just use a setting for?

"files.exclude": {
       "**/devfile.yaml": true
}

and the devfile won't appear in the project explorer

[sunix]

some projects maybe opened by different IDEs ... and I guess we don't want to pollute a project view with all the files for Jenkins, Che, VSCode, travis, .github, etc .... what ever the IDE you are using, it is a user preference to hide these files or not

[kadel]

What about Windows? Are the dotfiles hidden there also by default?

[maxandersen]

@maxandersen Why it is a problem when devfile.yaml shows up in the file explorer?

every time I generated project templates over the last 15 years there are an uproar when these files are included by default. They only are accepted if they are universally used across the development team - i.e. Dockerfile are a recent addition which been accepted as okey - but devfile will at least initially be used by a mere fraction of users of our standard projects thus adding it front and center will make people complain.

I'll keep it simple - if you want quarkus and other middleware runtimes to include support for devfile for che and odo by default it needs to be possible to hide it by default.

[maxandersen]

"files.exclude": {
"**/devfile.yaml": true
}

that means we or the user need to include such config out of the box of every IDE (adding even more files) and it will still be visible by default by default in a shell.

[maxandersen]

What about Windows? Are the dotfiles hidden there also by default?

yes they are. you don't see .git, .gitignore, .dockerignore, .vscode, .intellij, .eclipse neither.

[kadel]

@kadel at least we give the choice to the project team which files it wish to work with .devfile.yaml or devfile.yaml.

If we allow this then tools need to error out when both .devfile.yaml and devfile.yaml are present! Otherwise, this will lead to a lot of confusion and problems.

problem scenario

• 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 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.
• Tooling needs to error out when both styles of devfiles are used.

[sparkoo]

Current PR uses list of devfile names that is sorted by priority, so if multiple devfiles are found, we take the one nearest to the top.

I've just blocked the PR, because based on discussions here, redhat-developer/odo#3126 and devfile/api#61, we need to reconsider that.
cc: @skabashnyuk @mshaposhnik @gorkem @kadel @l0rd @maxandersen

[gorkem]

@sparkoo I do not think we should error. So if we discover both devfile.yaml and .devfile.yaml we use devfile.yaml but show a warning that simply states Both devfile.yaml and .devfile.yaml detected, using devfile.yaml.

[mshaposhnik]

We did that list of names configurable. So Che admin can add any amount of names he wants. But yes, in that case we need to check them all for presence. That's sounds logical, but may consume some workspace startup time. At the same time, dashboard indicates which file it picks for creating factory, so an attentive user should not fall into the trap.

[gorkem]

Good point with the dashboard and the startup time. I think we can start with this on Che. I am not even sure if we even need the configuration.

[mshaposhnik]

After some investigation, i found that we cannot show warning on factory accepting stage (at least without serious factory and dashb refactoring) :(
So i have created another one for dashb to make source filename more visible for the user: #17606
I think it should be enough for the time being.