To my understanding from the Visual studio multi environment docker docs here you can have multiple yml files for each of your environments. It says that the docker-compose.override.yml is used for development. I created a docker-compose.prod.yml like it says in this link but it doesn't run when I build under release, override continues to run. I am following the directions here which says to change configuration to release and build which should build the project for prod.
Not sure if this is related but I also noticed the prod is not nested like override is in the project.
I need to have two different compose files for prod and for dev but it seems override is not ignored when building for release and prod is not used.
Any ideas on how to get two different docker-compose files based on the environment? Just changing to release and building doesn't work as expected. Is the only way to do command line? Also, why doesn't prod nest?
docker-compose -f docker-compose.yml -f docker-compose.prod.yml up -d
A little late to the party but I faced the same challenge and found the solution below, hope it helps someone else out there.
If you want different behavior based on the build configuration (for
example, Debug or Release), add configuration-specific docker-compose
files. The files should be named according to the build configuration
(for example, docker-compose.vs.debug.yml and
docker-compose.vs.release.yml) and placed in the same location as the
docker-compose-override.yml file.
More info here
Related
I have a maven project structured:
/root
/CommonProject
/executable1
/executable2
/subroot
/subrootCommon
/...
So far I am trying to just deploy executable1.
I wanted to the project to use Java 19, I am fine with Java 17 if it's easier.
When I activate cloud shell, I am able to:
Change $JAVA_HOME to jdk 17
clone project
maven package it
run it in cloud shell.
However my project has no mapping for "/", just specific endpoints like "/test/hello" and I do not see anything in WebPreview on port 8080.
I have tried different ways to deploy, I am not familiar enough with Docker, so I tried CloudRun with Cloud Build with trigger from Source.
Here lies my current problem - every build has failed so far. It is using jdk 11 which is a problem (or at least one of them).
I have tried also adding cloudbuild.yaml or local Dockerfile just to deploy jar built manually, but I am still failing.
+FROM openjdk:17
+COPY root/target/executable1-1.0-SNAPSHOT-jar-with-dependencies.jar /home/user/var/run/executable1.jar
+CMD ["java", "-jar", "/home/user/var/run/executable1.jar"]
I have done the same steps to deploy, which were shown in how-to-guides or available online labs, so I think the issue is with the fact that maybe buildpacks do not process correctly projects with dependencies?
executable1 and executable2 depend on CommonProject. Do I need to split my big maven project into separate projects, to build each of them individually?
I have tried Dockerfile, cloudbuild.yaml, something like project.toml.
I would like to deploy for now just 1 project, at one point in the future all executable projects from this maven.
I have created Xamarin.UITest that can run locally on my desktop. My goal is to execute these test as a part of a post-build script to run UITest after the app has built as mentioned in this article below:
https://tomsoderling.github.io/AppCenter-Automated-UI-tests-on-build/
Below is my script
appcenter test run uitest --app "MY-APP" --devices 168683d9 --app-path $APPCENTER_OUTPUT_DIRECTORY/MyApp.Mobile.Droid.apk --test-series "myapp-mobile-test" --locale "en_US" --build-dir $APPCENTER_SOURCE_DIRECTORY/MyApp.Mobile.UITests/bin/Release --token MY-TOKEN --uitest-tools-dir $APPCENTER_SOURCE_DIRECTORY/packages/Xamarin.UITest.*/tools
When the script above is apart of my appcenter post build script, I get the following error:
Error: Cannot find test-cloud.exe, the path specified by "--uitest-tools-dir" was not found.
Please check that "/Users/vsts/agent/2.141.1/work/1/s/packages/Xamarin.UITest.2.2.6/tools" is a valid directory and contains test-cloud.exe.
Minimum required version is "2.2.0".
I think a lot of people are having trouble dealing with this actually and I know it has something to do with --uitest-tools-dir OR --build-dir variables.
Keep in mind this I am first trying to do this with Xamarin.Android, if successful I will try the Xamarin.iOS
One clue i do see is when Tom says "I had to chose to build the app solution file in my App Center CI build - not simply the iOS project like I normally would" in the noted article, but I am not quite sure how to do that or if is connected to why AppCenter cannot locate my test-cloud.exe I will also say that test-cloud.exe somehow comes from the Xamarin.UITest nuget, but I do not see any test-cloud.exe file in my Xamarin.Forms project.
This answer works, but it's pretty fragile.
The test-cloud.exe can't be located at packages/Xamarin.UITest.2.X.X/tools in projects that uses the old project structure (projects that use packages.config). For new projects (new .csproj formats), there is no such file in the path of the project. The only way I found to make it work on AppCenter is to use it from the NuGet package cache (/Users/vsts/.nuget/packages/xamarin.uitest/2.X.X)
Kudos to AppCenter Agents for helping me to resolve this. 2 things were required as indicated below:
Agent Anvesh says
Hi there, Thanks for the details, So seems like you are using a nuget as a PackageReference in your project(this means that there will be no package folder in your project, packages will be there at user profile).
So when you are trying to run the test as part of the app center build. Then in the shell script used the --uitest-tools-dir value as below
/Users/vsts/.nuget/packages/xamarin.uitest/2.2.6/lib/tools
So I modified my above script to add the below:
--uitest-tools-dir /Users/vsts/.nuget/packages/xamarin.uitest/2.2.6/tools \
Agent Shawn says
So I added the below
msbuild $APPCENTER_SOURCE_DIRECTORY/MyApp.Mobile.UITestProject.csproj
I am using ASP.NET Core and have used Visual Studio's Add Docker Support feature to get started. This adds a docker-compose.ci.build.yml file to my project which is supposed to be used on a CI server.
How do I build my Docker image from a compose file and push the image to my private Docker registry. I've tried the docker-compose build command:
docker-compose -f docker-compose.ci.build.yml build
However this outputs an error:
ci-build uses an image, skipping
I ran into a number of issues getting this to build initially. Fixes for me included updating Visual Studio 2017 to Update 4, updating the Visual Studio Tools for Docker extension, and updating/consolidating NuGet package references. In addition, in docker-compose.ci.build.yml I had to change the build image to microsoft/aspnetcore-build:1.0-2.0-stretch (see this GitHub issue for more details).
Assuming the docker-compose configurations are the same/similar to the default generated ones, try the following script:
$ docker-compose -f docker-compose.ci.build.yml up
$ docker-compose -f docker-compose.yml build
Bringing "up" docker-compose.ci.build.yml simply builds the project and then exits. The artifacts are published to the obj/Docker/publish folder. The "build" docker-compose.yml actually builds and tags the images using the artifacts from the obj/Docker/publish folder. I clean up at the end of my build script with the following:
$ docker-compose -f docker-compose.ci.build.yml down
For reference/inspiration-- This is working on a custom Linux build server and producing four Docker images from a single solution-- two ASP.NET Core apps and two .NET Core apps.
I managed to build docker container without docker-compose.ci.build.yml. I used .Net Core tasks to build and publish .Net Core app to "obj/Docker/publish" folder as dockerfile expects and then used docker-compose task to build the container and push it to private container repository.
I'm in the process of setting up a .NET Core project with Docker in Visual Studio 2017. I've created the project and added the docker-compose to the solution, and everything works.
But somehow, the VS won't build and run Docker with any configurations, other than Debug and Release.
I've created solution and project configurations named Preproduction and selected it, as well as created a docker-compose.vs.preproduction.yml file.
But when I run the preproduction configuration, the project runs as if Release was selected instead. The Build Output console also shows the following:
Debug
*docker-compose -f "docker-compose.yml" -f "docker-compose.override.yml" -f "docker-compose.vs.debug.yml" -p dockercompose3979710767*
Release
*docker-compose -f "docker-compose.yml" -f "docker-compose.override.yml" -f "docker-compose.vs.release.yml" -p dockercompose3979710767*
Preproduction
*docker-compose -f "docker-compose.yml" -f "docker-compose.override.yml" -f "docker-compose.vs.release.yml" -p dockercompose3979710767*
Notice the second yml file.
Somehow it uses the release file, and not the custom configuration file I've added.
Does anyone have any idea how to solve this, so docker will use my custom configurations?
Unfortunately it is not possible. After spending a lot of time to figure it out, it turned out that those two filenames are hardcoded into a DLL. Everything which is not 'DEBUG' will use the 'RELEASE' files.
Using different docker-compose.yml files by referencing them from different folder could be a solution, but since it is not a standard project but a Docker project, you don't have access to the post build events to copy the required files there. Furthermore you cannot have multiple Dockerfile, because it is also based on name convention.
You can use one version to develop and test, defined in the included files and create a script which builds everything manually based on your existing compose files and your extra.
I provide some non-standard solution for this issue can be solved. Here we go:
1) Get dnSPY tool (https://github.com/0xd4d/dnSpy/releases)
2) Install it
3) Find file Microsoft.Docker.dll (For me it was in "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Sdks\Microsoft.Docker.Sdk\tools" way.)
4) Get copy of this file (copy in some directory for example).
5) Open this dll in dnSpy.exe
6)Go Microsoft.Docker (version number) -> Microsoft.Docker.dll -> DockerComposeClient class -> MergedDockerComposeDocumentProvider private class -> GetDocuments private method
7) In this method you can see all file pathes and files used for build
8) RightClick on necessary string -> Edit IL Instructions
9) Edit what you need (as for me I was able to change docker-compose.override.yml to docker-compose.development.yml)
10) Save change
11) File -> Save Module and saving your upgraded DLL.
WHOILA!!! Actually
you must restart VS and maybe docker. After this your changes will be apply to pipeline build. Enjoy
We have the following project setup: Maven, Eclipse, Subversion. Eclipse Launch configurations are in a separate docs folder next to the pom.xml. The launch configurations run something like mvn clean install -Pdev or mvn tomee:run -pl something-ear
The good thing is that a shared run configuration is picked up by the IDE and shown in the External Tools run commands. This way, every developer that checks out this project immediately has access to run the build.
We would like to have something similar using IntelliJ IDEA, but I haven't found a good equivalent. What I have considered so far:
Share run scripts
My first idea was to replace the launch configurations with run scripts. I just could not figure out how to have those run scripts run inside IntelliJ IDEA just the way a Maven goal would be executed.
Share IDEA project configuration
The IDEA project configuration (specifically .idea/runConfigurations) inside the checked out directory is not a good solution. We have (speaking one IDEA project with different IDEA modules depending on the task at hand: as a developer you might need multiple IDEA modules (and sub-modules) in the same IDEA project
An IDEA project consisting of the following modules is not something unusal
projectA/trunk
projectB/tags/1.2
projectC/branches/some-change
My preferred solution would remove all IDE-specific configuration from the repository and have some kind of run definitions either in the project folder or a folder next to the pom.xml that a developer can run from the command line or from her IDE of choice.
The optimal solution would let me define something like this in the pom:
<runConfigs>
<default>clean install</default>
<container>tomee:run -pl something-ear</container>
</runConfigs>
This configuration would then be picked up by the IDE and provided as a run or launch configuration to the developer.
Any ideas or suggestions?
Thank you very much!
My current approach is a hybrid solution:
No configuration in the separate modules
One IDEA project configuration with run configurations managed in VCS
The .idea/runConfigurations directory is versioned separately from the project sources. It contains commands with a working directory set relative to the PROJECT_DIR:
<MavenRunnerParameters>
…
<option name="workingDirPath" value="$PROJECT_DIR$/path/to/submodule" />
</MavenRunnerParameters>
When setting up a new project, the developer also checks out this folder and has a set of pre-configured launch configurations for all projects. The downsides are
All launch configurations are managed centrally instead of with the module
The IDEA project directory has a fixed location relative to the modules. If you set up another project, you will have to change the run configurations
The setup does not clearly state how changes to the launch configurations are shared with other developers