Template Injection Dockerfile

[rjt-gupta]

This is required to build the custom image as part of template injection emulator.

As aiodocker_helper requires the remote path of the dockerfile to build the image, this needs to be merged first.

[coveralls]

Pull Request Test Coverage Report for Build 1064

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 77.014%

---

Totals
Change from base Build 1061:	0.0%
Covered Lines:	1310
Relevant Lines:	1701

---

💛 - Coveralls

[afeena]

I don't really understand the idea. Do you want to use the remote github path in the code for the dockerfile? Why don't you want to use local fileobj instead?

[rjt-gupta]

I don't really understand the idea. Do you want to use the remote github path in the code for the dockerfile? Why don't you want to use local fileobj instead?

Because I thought its much easier to build from remote than creating the tar file every time there is some change. Also, aiodocker prefered this method so thats why.

[afeena]

I see two problems with remote file:

• is it in 100% cases available?
• customization: we restrict users to our github file version and we don't allow to change dockerfile

You can build tar on the start of the tanner, so you will always have an updated version and Dockerfile can be easily updapted without any further changes in the code

[rjt-gupta]

I see two problems with remote file:

* is it in 100% cases available?

* customization: we restrict users to our `github` file version and we don't allow to change dockerfile

You can build tar on the start of the tanner, so you will always have an updated version and Dockerfile can be easily updapted without any further changes in the code

I guess availability is not an issue and I think this Dockerfile would only need to change when there is a change in the emulator itself which we will do if it happens, I don't think of any other possibility when user needs to change this.

But if you think fileobj would be better that's good too :)

[afeena]

I don't think fileobj is the best approach here. I just always want to discuss everything :) Let's do it like this - keep it remote for now and keep in mind that we should make a source configurable at some point :)

[rjt-gupta]

I don't think fileobj is the best approach here. Let's do it like this - keep it remote for now and keep in mind that we should make a source configurable at some point :)

Got it :)