feat: add port detection (#81)

[lstocchi]

it resolves #81

I added a doc to explain and keep note of how Alizer handles port detection for each framework -> https://github.com/redhat-developer/alizer/blob/34e7afae2ba2aaf4925ce2a554dc27de733c39e3/go/docs/port_detection.md

In few words it does 3 steps:

1. check if a dockerfile is present and try to get ports from here
2. check if a dockercompose exists and try to get ports from here
3. if the main language has any framework it uses the strategy built for that specific framework to try getting the ports

All yours!

130 files are related to projects used for testing. Everything in that test folder projectPortTesting can be skipped.

[jeffmaury]

Did not walk through the code but read you doc:

• compose file parsing based on web service name seems too restrictive why don't you use matching the build folder.
• Also seems compose files are also compose.yml or compose.yaml (see https://github.com/docker/awesome-compose)
• In compose seems ports directive can be used as well
• For Quarkus application.yaml or application.yml should be used in addition to application.properties
• For Quarkus there are other ways to specify configuration (.env files and global env variables)
• For other stacks maybe we should check if there are no other ways as well

[lstocchi]

Did not walk through the code but read you doc:

• compose file parsing based on web service name seems too restrictive why don't you use matching the build folder.
• Also seems compose files are also compose.yml or compose.yaml (see https://github.com/docker/awesome-compose)
• In compose seems ports directive can be used as well
• For Quarkus application.yaml or application.yml should be used in addition to application.properties
• For Quarkus there are other ways to specify configuration (.env files and global env variables)
• For other stacks maybe we should check if there are no other ways as well

Good points... covered everything except the last one. I'll try to dig on the documentation of other languages but this is something that can be also added later on if the rest works fine.

[jeffmaury]

See my comments.

[lstocchi]

@jeffmaury Added options to define port detection strategy to use.
By using the cli you can use such commands

alizer component /path/ -p="source" -p="docker"

or

alizer component /path/ -p="source,docker,compose"

If nothing is specified it uses the default "docker, compose, source"

[jeffmaury]

Strategies should be executed in sequence.
Also HTTP vs HTTPs should be checked

[jeffmaury]

Quarkus may use QUARKUS_HTTP_SSL_PORT or QUARKUS_HTTP_PORT or both based on QUARKUS_HTTP_INSECURE_REQUEST.
See https://quarkus.io/guides/all-config and use https as a filter.

[jeffmaury]

I think all strategies should be used. ex for Quarkus and deploy we can have a default port in source and port in dockerfile.

[lstocchi]

This is the dotnet _enricher and dot net languages do not have any source detection for the moment. This is why only those 2 algos are in the switch.

For the second point i wonder what's the point of performing all detections.
If you are deploying the app then the port in dockerfile should have priority over the source. Probably it would be the same otherwise there is some issue. If you work locally the one in the source code should be used. By defining the strategy order you should take what you need, no?
The only case it can be useful is if the port in the dockerfile is wrong. E.g it tells to open port 9090 and the source code listen to 9091. in that case it's a user fault.
By executing all strategies we could end up opening more ports than those actually required if some file is dirty.

[jeffmaury]

LGTM