(In reply to Jake Watkins [:dividehex] from comment #12) > Baking these tools into the base images or having them pre-installed across the workers is an anti-pattern for test prerequisites. Why is that an anti-pattern ? You have Python installed for instance. > Best practices dictates we should be couple a tests prerequisites with the tasks setup harness and not build it directly into the underlying system which does not change and iterate as fast as tests and other parts 'in-tree'. ffmpeg is a very common system package that is often pre-installed in some distribution. It's a system level package. Once it's added, it's just a binary that's available, like "iproute" or "nmap". I don't really get the fear here. > Tarek, sorry to push back here but I'd like to work out why this is, 'quite a pain to manage this system install properly from mach on all platform' and figure out a more sustainable solution. Could you elaborate on this? Sure, we tried in the past and failled. If we are installing them through mach in a way that works both locally and in the CI, we are facing numerous combinations of systems and environments. We have tried that in "mach browsertime" and had many issues. Sometimes because ffmpeg was already there, sometimes because the way we would install it was not the right way for the given environment. If we do this, we are also going to be dependent on worker changes, and will have to maintain the mach command when the system is modified (like changing the base distro in the future or such thing) This package should be considered part of the system, and therefore be installed with the system, because it would be done with other packages you deploy (via apt-get or something else) and is part of a whole. Asking devs to install it themselves, and having them properly installed removes all the issues, and avoid maintaining a mach command that will be half broken. I am curious to understand why having it added in workers is a problem.
Bug 1656830 Comment 16 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Jake Watkins [:dividehex] from comment #12) > Baking these tools into the base images or having them pre-installed across the workers is an anti-pattern for test prerequisites. Why is that an anti-pattern ? You have Python installed for instance. > Best practices dictates we should be couple a tests prerequisites with the tasks setup harness and not build it directly into the underlying system which does not change and iterate as fast as tests and other parts 'in-tree'. ffmpeg is a very common system package that is often pre-installed in some distribution. It's a system level package. Once it's added, it's just a binary that's available, like "iproute" or "nmap". I don't really get the fear here. > Tarek, sorry to push back here but I'd like to work out why this is, 'quite a pain to manage this system install properly from mach on all platform' and figure out a more sustainable solution. Could you elaborate on this? Sure, we tried in the past and failled. If we are installing them through mach in a way that works both locally and in the CI, we are facing numerous combinations of systems and environments. We have tried that in "mach browsertime" and had many issues. Sometimes because ffmpeg was already there, sometimes because the way we would install it was not the right way for the given environment. If we do this, we are also going to be dependent on worker changes, and will have to maintain the mach command when the system is modified (like changing the base distro in the future or such thing) This package should be considered part of the system, and therefore be installed with the system. It should be done with other packages you deploy (via apt-get or something else) and be part of a whole. Asking devs to install it themselves, and having them properly installed in the CI removes all the issues, and avoid maintaining a mach command that will be half broken most of the time. I am curious to understand why having it added in workers is a problem. Not sure what "not in-tree" means in this context.
(In reply to Jake Watkins [:dividehex] from comment #12) > Baking these tools into the base images or having them pre-installed across the workers is an anti-pattern for test prerequisites. Thanks for the feeback and help Why is that an anti-pattern ? You have Python installed for instance. > Best practices dictates we should be couple a tests prerequisites with the tasks setup harness and not build it directly into the underlying system which does not change and iterate as fast as tests and other parts 'in-tree'. ffmpeg is a very common system package that is often pre-installed in some distribution. It's a system level package. Once it's added, it's just a binary that's available, like "iproute" or "nmap". I don't really get the fear here. > Tarek, sorry to push back here but I'd like to work out why this is, 'quite a pain to manage this system install properly from mach on all platform' and figure out a more sustainable solution. Could you elaborate on this? Sure, we tried in the past and failled. If we are installing them through mach in a way that works both locally and in the CI, we are facing numerous combinations of systems and environments. We have tried that in "mach browsertime" and had many issues. Sometimes because ffmpeg was already there, sometimes because the way we would install it was not the right way for the given environment. If we do this, we are also going to be dependent on worker changes, and will have to maintain the mach command when the system is modified (like changing the base distro in the future or such thing) This package should be considered part of the system, and therefore be installed with the system. It should be done with other packages you deploy (via apt-get or something else) and be part of a whole. Asking devs to install it themselves, and having them properly installed in the CI removes all the issues, and avoid maintaining a mach command that will be half broken most of the time. I am curious to understand why having it added in workers is a problem. Not sure what "not in-tree" means in this context.
(In reply to Jake Watkins [:dividehex] from comment #12) > Baking these tools into the base images or having them pre-installed across the workers is an anti-pattern for test prerequisites. Thanks for the feeback and help Why is that an anti-pattern ? You have Python installed for instance. > Best practices dictates we should be couple a tests prerequisites with the tasks setup harness and not build it directly into the underlying system which does not change and iterate as fast as tests and other parts 'in-tree'. ffmpeg is a very common system package that is often pre-installed in some distribution. It's a system level package. Once it's added, it's just a binary that's available, like "iproute" or "nmap". I don't really get the fear here. > Tarek, sorry to push back here but I'd like to work out why this is, 'quite a pain to manage this system install properly from mach on all platform' and figure out a more sustainable solution. Could you elaborate on this? Sure, we tried in the past and failed. If we are installing them through mach in a way that works both locally and in the CI, we are facing numerous combinations of systems and environments. We have tried that in "mach browsertime" and had many issues. Sometimes because ffmpeg was already there, sometimes because the way we would install it was not the right way for the given environment. If we do this, we are also going to be dependent on worker changes, and will have to maintain the mach command when the system is modified (like changing the base distro in the future or such thing) This package should be considered part of the system, and therefore be installed with the system. It should be done with other packages you deploy (via apt-get or something else) and be part of a whole. Asking devs to install it themselves, and having them properly installed in the CI removes all the issues, and avoid maintaining a mach command that will be half broken most of the time. I am curious to understand why having it added in workers is a problem. Not sure what "not in-tree" means in this context.