adding proposal for dockerfile components

[mike-hoang]

What does this PR do?

Initial draft for improving port detection logic for cases where the dockerfiles are not found in a component.

Which issue(s) does this PR fix

fixes #244

PR acceptance criteria

Testing and documentation do not need to be complete in order for this PR to be approved. We just need to ensure tracking issues are opened.

• Unit/Functional tests

• Documentation

How to test changes / Special notes to the reviewer

[elsony]

Why do we call it orphan_component instead of Dockerfile component?

[elsony]

In the example above, what is the priority of the search order? If there is a Dockerfile at the root, do we consider that as a Dockerfile component?

[mike-hoang]

We decided not to use "docker_component" or anything that is closely coupled to Dockerfiles so we can resuse the field if there were ever another "orphaned" component (as in we wanted to define a component like Dockerfile where there isn't really a language or framework tied to it.)

We also didn't want to use the existing field component as it doesn't really match the others (i.e. C#, F#, Go, Java, etc) because they're languages, compared to a single Dockerfile.

Also open to renaming the field too if there's something more accurate

[mike-hoang]

In the example above, the output would look something like this:

[
  {
    // component found; since there is a dockerfile inside, it will use the Dockerfile strategy for port detection
    "Name": ...,
    "Path": "repo-being-detected-by-alizer/component/",
    ...
  },
  {
    // the orphaned component where just the Dockerfile is used
    "Name": ...,
    "Path": "repo-being-detected-by-alizer/"
  }
]

As to the priority of the search, I think currently, the order would be random / depends on the list of component paths found. Regardless of order, it will go through both components as reflected in the output.

The proposed changes will consider the single Dockerfile in the root as an "orphaned" component

[elsony]

Do you mean Dockerfile support will be handled differently in those two cases? Do we still try to do port detection for Dockerfile on root? It is still not clear to me why those two dockerfile cases will need to be processed differently.

[mike-hoang]

+1 for nonlanguage_component

[kim-tsao]

or container_component? Since Dockerfile is part of language.yaml, Linguist considers it a language. To call it a nonlanguage would be confusing in this context. I know you mentioned you wanted to make this generic enough to future proof this but if we ever do encounter some other use case, maybe we can just add a new component classification and treat it in the same way as container_component?

[mike-hoang]

That is a good point, I can't really think of another use case and creating a new component classification wouldn't be hard since each enricher is language specific

If we did want to stick with a generic name, maybe we could use domain_specific_component? Docker does consider the Dockerfile syntax to be a DSL

[kim-tsao]

As long as we are confident enough that DSLs are always going to be processed this way: https://en.wikipedia.org/wiki/Domain-specific_language

[mike-hoang]

Settled on container_component with the intent that new component classifications can be created in the future if needed

[mike-hoang]

PR moved to devfile/alizer#3