Closed orviz closed 3 years ago
As I understand from the description of this issue, this doesn't seems to be a bug, but an expected behaviour. Taking as example the work produced in Worsica TS, the docker-compose.yml should reflect the content planed for the workspace and not the opposite. This is important so we can keep a logical definition for the reference source. Going deeper to the details, when using the triggered branch from github or other git management system, they will pass the variables with independent definitions not following a standard. So when gitSCM pick that metadata it will produce the workspace by default using the provided properties. That's why this kind of details can only be standardized in an above level with a template approach, as we can do using SQAaaS API or Web. So I answer to this issue as wontfix.
Say we have
/jepl
folder as the volume's target in docker-compose.yml:config: project_repos
to checkout a foo repo, its content will be stored under /jepl/fooWe should homogeneize this behaviour so that in both cases, the repo is placed in the same path.