Dockerscript should not need to clone the repo that it is in

[spham-amzn]

Currently, the Dockerfile designed for this project will clone from the same repo that it is currently already cloned in.

ARG ROSCON_DEMO_REPO=https://github.com/o3de/ROSConDemo.git
ARG ROSCON_DEMO_BRANCH=development

The disadvantage of this is that you cannot make any changes or modifications to test with a Dockerfile unless the changes were merged into the repo. Instead, the Dockerfile should copy the current source into the image instead, but still clone from the other repos

[adamdbrw]

@spham-amzn any progress on this one?

[jhanca-robotecai]

I faced the same question while implementing docker environment for Ros2ProjectTemplate and I decided to keep it as it is. The docker arguments that you showed allow you to change the repo (you can use your own fork) and the branch. Please note, that you can even use a commit's hash code rather than a branch name:

        && git clone $ROSCON_DEMO_REPO \
        && git -C $WORKSPACE/ROSConDemo checkout $ROSCON_DEMO_BRANCH \

(if we wanted to limit ourselves to branch level, we could have used more optimal git clone --depth 1 --branch <branch url instead, which does not pull the whole repository)

[adamsj-ros]

Why not just add o3de and o3de-extras as submodules and then COPY . /data/workspace? Alternatively, clone only o3de and o3de-extras still using the COPY command in the Dockerfile.

[michalpelka]

I think this issue is generalized to other projects.

I am using docker files as a developer's tool that improves my overall experience in implementing new features and maintaining those repos.

In the current approach (with cloning inside docker) I can use the docker script to test a build against a clean environment. With copying/mapping the workspace I can run into issues:

• some product assets in the Cache directory can be moved to the docker environment. It can lead to serious problems since O3DE does not check the version of product assets and those should be built exclusively for one version of O3DE. Can have my manifest set to developer build of o3de and generate product assets for newer versions, most likely causing an unstable experience.
• The 'Users' directory is also shared with the container, so the user's overrides will be migrated from the developer's environment. If you are planning to move to a copy repo, please make sure that product assets and user settings will be filtered out. Please do not map the whole directory. Cloning takes a while but is very robust and independent of the state of the repo on the host.

[spham-amzn]

I think we can close this issue. The intent of docker is to provide a consistent environment that is set against known tags if possible. I think this request ultimately defeats that purpose. While the dockerscript itself exists within the same repo that it clones, it should be able to stand alone outside of the repo.