Ability to produce future-proof Containerfile about ansible-builder

[kdelee]

• Put the installed collections into the build context, and only ADD them in the Containerfile, so that results of ansible-galaxy collection install will not give different outcomes from one build to the next

TBH I kinda thought this was way it was going to go down but I do see point of then Containerfile is not very portable, has to go w/ whole context dir.

[AlanCoding]

Yes, but I worry that it over-simplifies the problem.

The initial implementation I'm working on is likely to knowingly violate the idea here, just to have a work-in-progress that we can make some testing progress with.

If we use ADD to solve these, then it makes more sense to package the collection tar.gz files in the build context, as opposed to the fully installed file structure of the collections. I filed ansible/ansible#70429 as I was trying to define the limitations of that. It's not a home-run, it might work in some cases, but not all.

---

It's also not necessary wrong to have a Containerfile that pulls in new versions. It can be desirable to use the up-to-date versions, and produce images on the fly. What if you wanted to put the build context into your project source? You should either want ansible-builder to pin everything, or not pin anything. You just don't want a mix of the two.

If you want everything un-pinned... then the best solution is to take all of the logic and put it into the Containerfile. In that case, maybe the Containerfile installs ansible-builder and then calls an ansible-builder command. Instead of writing a Containerfile, this command will just run the instructions directly.

That would look a whole lot like adding a flag to the collection install command, like ansible-galaxy collection install -r requirements.yml --system-deps.