microsoft / DockerTools

Tools For Docker, including Visual Studio Provisioning and Publishing
Other
175 stars 26 forks source link

DockerComposeBaseFilePath does not also affect obj\Docker\docker-compose.vs*.yml #233

Open DaleyKD opened 4 years ago

DaleyKD commented 4 years ago

I'm trying to use numerous .sln files in the same root directory of a massive project. Trying to break it into smaller chunks, I have the need for different docker-compose files.

In my .dcproj file, I have set:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="15.0" Sdk="Microsoft.Docker.Sdk">
  <PropertyGroup Label="Globals">
    <ProjectVersion>2.1</ProjectVersion>
    <DockerTargetOS>Linux</DockerTargetOS>
    <ProjectGuid>651a3311-e177-4dfb-871e-c4f92aae6208</ProjectGuid>
    <DockerLaunchAction>LaunchBrowser</DockerLaunchAction>
    <DockerServiceUrl>{Scheme}://localhost:{ServicePort}/</DockerServiceUrl>
    <DockerServiceName>myweb</DockerServiceName>
    <DockerComposeBaseFilePath>docker-compose-corewebs</DockerComposeBaseFilePath>
  </PropertyGroup>
  <ItemGroup>
    <None Include="docker-compose-corewebs.override.yml">
      <DependentUpon>docker-compose-corewebs.yml</DependentUpon>
    </None>
    <None Include="docker-compose-corewebs.yml" />
    <None Include=".dockerignore" />
  </ItemGroup>
</Project>

The DockerComposeBaseFilePath does a good job of affecting the docker-compose cmd that runs for the first two -f args, but it shares the same docker-compose.vs.debug.partial.g.yml file as the other .dcprojs.

It generates: docker-compose -f "C:\src\k\docker-compose-corewebs.yml" -f "C:\src\k\docker-compose-corewebs.override.yml" -f "C:\src\k\obj\Docker\docker-compose.vs.debug.g.yml" -p dockercomposecorewebs15517584978595564736 --no-ansi config

I would expect it to generate: docker-compose -f "C:\src\k\docker-compose-corewebs.yml" -f "C:\src\k\docker-compose-corewebs.override.yml" -f "C:\src\k\obj\Docker\docker-compose**-corewebs**.vs.debug.g.yml" -p dockercomposecorewebs15517584978595564736 --no-ansi config (sans asterisks)

DaleyKD commented 4 years ago

Any update on this?

pratiksanglikar commented 4 years ago

Hi @DaleyKD, The file docker-compose.vs.debug.g.yml gets generated each time you debug. That means, even though the name of the file would be same for different dcproj, it would be overwritten each time you debug any project. Please let us know if this behavior is breaking any of your scenarios?

DaleyKD commented 3 years ago

@pratiksanglikar : I understand. I meant, instead of you using a file named docker-compose.vs.debug.g.yml, could you not use a static named file and make it based upon the DockerComposeBaseFilePath?

var partialYmlFileName = $"{DockerComposeBaseFilePath}.vs.debug.g.yml";
pratiksanglikar commented 3 years ago

Hi @DaleyKD, The DockerComposeBaseFilePath can contain characters that indicate relative paths. i.e. ..\ etc. So, using this variable as a prefix for generated files may not be the optimal option.

However, I would like to understand your use case and can probably give you a workaround on what you are trying to achieve.

yunyanng commented 1 year ago

Hi, I have a Test configuration which the value of DockerComposeBaseFilePath is docker-compose-tests. I want to override the entrypoint for this configuration as such:

entrypoint: dotnet test --logger "trx;LogFileName=/tests/test-results.xml"

I don't want it to be applied to other configurations (e.g. Debug, Release). I know we can override the docker-compose.vs.*.g.yml by placing a file named docker-compose.vs.*.yml in the same directory as the docker-compose.yml file. Is it possible to make the naming convention of the filename of docker-compose.vs.*.yml to follow the value of DockerComposeBaseFilePath so for my use case, it would be docker-compose-tests.vs.*.yml?

NCarlsonMSFT commented 1 year ago

@yunyanng as of now DockerComposeBaseFilePath does not support that. The closest you could get to this behavior would be to create a separate .dcproj in Its own folder that uses DockerComposeBaseFilePath to re-use the compose files from the original project. The new project could then have its own docker-compose.vs.*.yml files that would not impact the original project.

yunyanng commented 1 year ago

@NCarlsonMSFT I would stick to the solution you suggested until the behavior is supported. Thanks!