Is there anything wrong with a all inclusive custom image forpipeline?

[Erfang Chen]

Here is what I plan to do in our Pipeline, please let me know if this violates any best practices

We typically deploy Java based app servers to AWS elastic beanstalk or lambda. Therefore, our image shall contain

 - mvn

 - python3

 - pip

 - awscli

But we also have custom JFrog instance hosting our artifacts, thus we need to mv our own {{settings.xml}} in {{/root/.m2/settings.xml}

This way, my 1 image can handle everything from running tests to upload the application JARs to AWS and without having to specify a {{mvn -s <path to settings>}} on each command

Does this violate any known best practices at all?

[Jeroen De Raedt · Accepted solution]

Hi @Erfang Chen,

the approach that you describes sounds like a sensible thing to do. By creating your custom optimised image, you won't lose time installing dependencies on run time and thus make your overall build time smaller. 

I am not sure if you are planning to also put JFrog credentials in your settings.xml file - but if you do, make sure you make the Docker image private. Alternatively, you could write a simple script that injects your authentication credentials at runtime (where the credentials would be injected from Bitbucket Pipelines secured variables). This way you don't have to burn credentials into your Docker image. 

[Erfang Chen]

Thanks @Jeroen De Raedt, this make sense. When you say inject credentials through Bitbucket Pipeline secured variables, you mean environment variables right? This is what our team is currently doing

[Jeroen De Raedt]

Correct, these ones: https://confluence.atlassian.com/bitbucket/environment-variables-794502608.html 

You declare them in the Pipelines UI, and they will be made available as environment variables.