Date: Fri, 2 Jun 2023 17:06:40 -0400
On 6/2/23 4:46 PM, René Ferdinand Rivera Morell via SG15 wrote:
> On Fri, Jun 2, 2023 at 2:38 PM Tom Honermann <tom_at_[hidden]> wrote:
>> On 6/2/23 2:52 PM, René Ferdinand Rivera Morell via SG15 wrote:
>>> I'll need to do some research on the possibility of having side data
>>> as a mechanism. I.e. go find out how it would work in the variety of
>>> build, packaging, and compiler tools that are available. But I'm
>>> wondering, since both Gaby and Olga mentioned it, if you can give
>>> examples of running such tools in size constrained environments and
>>> multiple tools needing to communicate. As I'm not familiar with
>>> running compilers, build systems, and package managers outside of
>>> desktop environments.
>> CI deployments are often configured such that development tools are
>> deployed into a fresh OS image as part of job processing. The smaller
>> the size of the tools, the lower the setup overhead, the faster the job
>> throughput.
> Interesting.. The CI systems I work with are either in-house to build
> rather large Unreal Engine based projects, or cloud based ones to
> build & test (in comparison) small projects like Boost C++ Libraries.
> For the former the size & resources doesn't matter at the scale of
> adding a command line option in a tool having an impact on anything.
> As everything is pre-installed as it's impractical to do otherwise.
> And as some parts of it run in a local network distributed compute
> structure. For the cloud based ones, yes, most of the setup of OS and
> tools is pre-imaged somehow. So I guess I'm trying to understand what
> you mean by "fresh OS image". Does that mean you install an empty OS
> and then fresh install tools and then build/test? Something else?
In at least some of the environments I've worked in, there have been a
limited number of base OS images provided and customization gets
expensive due to frequent updates and differing project and project
version dependencies. That means that suitable images are constructed on
demand to meet job requirements.
By "install" I mean some form of making development tools available on
the image. For a few annoying products, that means having to automate
execution of an installer, but most development tools are sufficiently
well behaved that copying an "installed" image of the tool from
somewhere else to a local location works fine.
Tom.
> On Fri, Jun 2, 2023 at 2:38 PM Tom Honermann <tom_at_[hidden]> wrote:
>> On 6/2/23 2:52 PM, René Ferdinand Rivera Morell via SG15 wrote:
>>> I'll need to do some research on the possibility of having side data
>>> as a mechanism. I.e. go find out how it would work in the variety of
>>> build, packaging, and compiler tools that are available. But I'm
>>> wondering, since both Gaby and Olga mentioned it, if you can give
>>> examples of running such tools in size constrained environments and
>>> multiple tools needing to communicate. As I'm not familiar with
>>> running compilers, build systems, and package managers outside of
>>> desktop environments.
>> CI deployments are often configured such that development tools are
>> deployed into a fresh OS image as part of job processing. The smaller
>> the size of the tools, the lower the setup overhead, the faster the job
>> throughput.
> Interesting.. The CI systems I work with are either in-house to build
> rather large Unreal Engine based projects, or cloud based ones to
> build & test (in comparison) small projects like Boost C++ Libraries.
> For the former the size & resources doesn't matter at the scale of
> adding a command line option in a tool having an impact on anything.
> As everything is pre-installed as it's impractical to do otherwise.
> And as some parts of it run in a local network distributed compute
> structure. For the cloud based ones, yes, most of the setup of OS and
> tools is pre-imaged somehow. So I guess I'm trying to understand what
> you mean by "fresh OS image". Does that mean you install an empty OS
> and then fresh install tools and then build/test? Something else?
In at least some of the environments I've worked in, there have been a
limited number of base OS images provided and customization gets
expensive due to frequent updates and differing project and project
version dependencies. That means that suitable images are constructed on
demand to meet job requirements.
By "install" I mean some form of making development tools available on
the image. For a few annoying products, that means having to automate
execution of an installer, but most development tools are sufficiently
well behaved that copying an "installed" image of the tool from
somewhere else to a local location works fine.
Tom.
Received on 2023-06-02 21:06:42