7 ms·

Containerize the build environment so everything is captured (dependencies, build tools, etc)

by akdev1l 2y ago

carlmr 2y ago
If you're not containerizing your CI/CD, you're really lost.
- maccard 2y ago
  How do I containerize building desktop apps for windows with MSVC?
  - eru 2y ago
    Wine? Less snarky: https://learn.microsoft.com/en-us/virtualization/windowscontainers/about/ https://learn.microsoft.com/en-us/virtualization/windowscont... seems to be a thing? And in any case, you can use VMs instead of containers.
    - maccard 2y ago
      You know, I'd love to run MSVC in Wine on a ubuntu container. I bet it would be quicker. I've had the unfortunate pleasure of working with Windows Containers in the past. They are Containers in the sense that you can write a dockerfile for them, and they're somewhat isolated, but they're no better than a VM in my experience. > And in any case, you can use VMs instead of containers. They're not the same thing. If that's the case running linux AMI's on EC2 should be the same as containers.
      - akdev1l 2y ago
        It’s the same thing for the purposes of capturing the build environment. It doesn’t really matter if you have to spin up a Linux instances and then run your build environment as a container there vs spinning up a windows VM.
- akoboldfrying 2y ago
  That might be the case if Docker did in fact guarantee (or at least make it easy to guarantee) deterministic builds -- but it doesn't really even try: 1. Image tags ("latest", etc.) can change over time. Does any layer in your Dockerfile -- including inside transitive deps -- build on an existing layer identified by tag? If so, you never had reproducibility. 2. Plenty of Dockerfiles include things like "apt-get some-tool" or its moral equivalent, which will pull down whatever is the latest version of that tool. It's currently common and considered normal to use these "features". Until that changes, Docker mostly adds only the impression of reproducibility, but genuine weight and pain.
  - tsimionescu 2y ago
    The advantage that Docker brings isn't perfect guaranteed reusability, it's complete independence (or as close you can easily get while not wasting resources on VMs) from the system on which the build is running, plus some resuability in practice in a certain period of time, and given other good practices. Sure, if I try to rebuild a docker image from 5 years ago, it may fail, or produce something different, because it was pulling in some packages that have changed significantly in apt, or perhaps pip has changed encryption and no longer accepts TLS1.1 or whatever. And if you use ':latest' or if your team has a habit of reusing build numbers or custom tags, you may break the assumptions even sooner. But even so, especially if using always incremented build numbers as image tags, a docker image will work the same way om the Jenkins system, the GitHub Actions pipeline, and every coworker's local build, for a while.
  - akdev1l 2y ago
    1. Use a hash for the base images. 2. The meaning of “latest” is dependent on what base images you are using. Using UBI images for example means your versions are not going to change because redhat versions don’t really change. But really containerizing the build environment is not related to deterministic builds as there’s a lot more work needed to guarantee that. Including possible changes in the application itself. Lastly you don’t need to use docker or dockerfiles to build containers. You can use whatever tooling you want to create a rootfs and then create an image out of that. A nifty way of actually guaranteeing reproducibility is to use nix to build a container image.
- lmm 2y ago
  Only if your tech stack is bad (i.e. Python). My maven builds work anywhere with an even vaguely recent maven and JVM (and will fail-fast with a clear and simple error if you try to run them in something too old), no need to put an extra layer of wrapping around that.
  - akdev1l 2y ago
    except you need to install the correct Java version and maven (we really should be using gradle by now) Also in many projects there’s things other than code that need to be “built” (assets, textures, translations, etc). Adding custom build targets to maven’s build.xml is truly not ideal then there’s people who actually try to write logic in there. That’s objectively worse than the YAML hell we were complaining about at the top of the thread.
    - lmm 2y ago
      > you need to install the correct Java version and maven Like I said, any version from the last, like, 10+ years (Java and Maven are both serious about backward compatibility), and if you install an ancient version you at least get fail-fast with a reasonable error. > we really should be using gradle by now We really shouldn't. > Adding custom build targets to maven’s build.xml is truly not ideal then there’s people who actually try to write logic in there. Maven doesn't have a build.xml, are you thinking of ant? With maven you write your custom build steps as build plugins, and they're written in plain old Java (or Kotlin, or Scala, or...) code, as plain old Maven modules, with the same kind of ordinary unit testing as your regular code; all your usual code standards apply (e.g. if you want to check your test coverage, you do it the same way as for your regular code - indeed, probably the same configuration you set up for your regular code is already getting applied). That's a lot better than YAML.
  - necovek 2y ago
    It's trivial to control your Python stack with things like virtualenv (goes back to at least 2007) and has been for ages now (I don't really remember the time when it wasn't, and I've been using Python for 20+ years). What in particular did you find "bad" with Python tech stack? (I've got my gripes with Python and the tooling, but it's not this — I've got bigger gripes with containers ;-))
darthwalsh 2y ago
I'm not sold on using containers for macOS desktop apps...
necovek 2y ago
If you don't value your and your developer's time, certainly, containerize everything. I've rarely seen a feedback loop with containers that's not longer than 10s only due to containerization itself, and that breaks the "golden" 10s rule (see https://www.nngroup.com/articles/response-times-3-important-limits/ https://www.nngroup.com/articles/response-times-3-important-...). If you aim for quicker turn-around (eg. just running a single test in <1s), you'll have to either aggressively optimize containers (which is pretty non-idiomatic with Docker containers in particular), or do away with them.
- crabmusket 2y ago
  Are you talking about CI or local development? Why would you run a single test in CI? And why would a container add 10+ seconds to a local task?
  - necovek 2y ago
    I am talking about either, because the GP post was about "containerizing a build environment": you need your project built to either run it in CI or locally. Why would it be slow? It needs to be rebuilt? (on a fast moving project with mid-sized or large team, you'll get dependency or Dockerfile changes frequently) It needs to restart a bunch of dependent services? Container itself is slow to initialize? Caching of Docker layers is tricky, silly (you re-arrange a single command line and poof, it's invalidated, including all the layers after) and hard to make the most of. If you can't get a single test running in <1s, you are never going to get a full test suite running in a couple of seconds, and never be able to do an urgent deploy in <30s.
- akdev1l 2y ago
  > I've rarely seen a feedback loop with containers that's not longer than 10s only due to containerization itself Sounds like a skill issue tbh. `time podman run —-rm -it fedora:latest echo hello` will return in a few milliseconds, whatever delay you are complaining about would be from the application running in the container. Lastly containers != docker.

Containerize the build environment so everything is captured (dependencies, build tools, etc)

carlmr 2y ago

If you're not containerizing your CI/CD, you're really lost.

maccard 2y ago
How do I containerize building desktop apps for windows with MSVC?
- eru 2y ago
  Wine? Less snarky: https://learn.microsoft.com/en-us/virtualization/windowscontainers/about/ https://learn.microsoft.com/en-us/virtualization/windowscont... seems to be a thing? And in any case, you can use VMs instead of containers.
  - maccard 2y ago
    You know, I'd love to run MSVC in Wine on a ubuntu container. I bet it would be quicker. I've had the unfortunate pleasure of working with Windows Containers in the past. They are Containers in the sense that you can write a dockerfile for them, and they're somewhat isolated, but they're no better than a VM in my experience. > And in any case, you can use VMs instead of containers. They're not the same thing. If that's the case running linux AMI's on EC2 should be the same as containers.
    - akdev1l 2y ago
      It’s the same thing for the purposes of capturing the build environment. It doesn’t really matter if you have to spin up a Linux instances and then run your build environment as a container there vs spinning up a windows VM.
akoboldfrying 2y ago
That might be the case if Docker did in fact guarantee (or at least make it easy to guarantee) deterministic builds -- but it doesn't really even try: 1. Image tags ("latest", etc.) can change over time. Does any layer in your Dockerfile -- including inside transitive deps -- build on an existing layer identified by tag? If so, you never had reproducibility. 2. Plenty of Dockerfiles include things like "apt-get some-tool" or its moral equivalent, which will pull down whatever is the latest version of that tool. It's currently common and considered normal to use these "features". Until that changes, Docker mostly adds only the impression of reproducibility, but genuine weight and pain.
- tsimionescu 2y ago
  The advantage that Docker brings isn't perfect guaranteed reusability, it's complete independence (or as close you can easily get while not wasting resources on VMs) from the system on which the build is running, plus some resuability in practice in a certain period of time, and given other good practices. Sure, if I try to rebuild a docker image from 5 years ago, it may fail, or produce something different, because it was pulling in some packages that have changed significantly in apt, or perhaps pip has changed encryption and no longer accepts TLS1.1 or whatever. And if you use ':latest' or if your team has a habit of reusing build numbers or custom tags, you may break the assumptions even sooner. But even so, especially if using always incremented build numbers as image tags, a docker image will work the same way om the Jenkins system, the GitHub Actions pipeline, and every coworker's local build, for a while.
- akdev1l 2y ago
  1. Use a hash for the base images. 2. The meaning of “latest” is dependent on what base images you are using. Using UBI images for example means your versions are not going to change because redhat versions don’t really change. But really containerizing the build environment is not related to deterministic builds as there’s a lot more work needed to guarantee that. Including possible changes in the application itself. Lastly you don’t need to use docker or dockerfiles to build containers. You can use whatever tooling you want to create a rootfs and then create an image out of that. A nifty way of actually guaranteeing reproducibility is to use nix to build a container image.
lmm 2y ago
Only if your tech stack is bad (i.e. Python). My maven builds work anywhere with an even vaguely recent maven and JVM (and will fail-fast with a clear and simple error if you try to run them in something too old), no need to put an extra layer of wrapping around that.
- akdev1l 2y ago
  except you need to install the correct Java version and maven (we really should be using gradle by now) Also in many projects there’s things other than code that need to be “built” (assets, textures, translations, etc). Adding custom build targets to maven’s build.xml is truly not ideal then there’s people who actually try to write logic in there. That’s objectively worse than the YAML hell we were complaining about at the top of the thread.
  - lmm 2y ago
    > you need to install the correct Java version and maven Like I said, any version from the last, like, 10+ years (Java and Maven are both serious about backward compatibility), and if you install an ancient version you at least get fail-fast with a reasonable error. > we really should be using gradle by now We really shouldn't. > Adding custom build targets to maven’s build.xml is truly not ideal then there’s people who actually try to write logic in there. Maven doesn't have a build.xml, are you thinking of ant? With maven you write your custom build steps as build plugins, and they're written in plain old Java (or Kotlin, or Scala, or...) code, as plain old Maven modules, with the same kind of ordinary unit testing as your regular code; all your usual code standards apply (e.g. if you want to check your test coverage, you do it the same way as for your regular code - indeed, probably the same configuration you set up for your regular code is already getting applied). That's a lot better than YAML.
- necovek 2y ago
  It's trivial to control your Python stack with things like virtualenv (goes back to at least 2007) and has been for ages now (I don't really remember the time when it wasn't, and I've been using Python for 20+ years). What in particular did you find "bad" with Python tech stack? (I've got my gripes with Python and the tooling, but it's not this — I've got bigger gripes with containers ;-))

darthwalsh 2y ago

I'm not sold on using containers for macOS desktop apps...

necovek 2y ago

If you don't value your and your developer's time, certainly, containerize everything. I've rarely seen a feedback loop with containers that's not longer than 10s only due to containerization itself, and that breaks the "golden" 10s rule (see https://www.nngroup.com/articles/response-times-3-important-limits/ https://www.nngroup.com/articles/response-times-3-important-...). If you aim for quicker turn-around (eg. just running a single test in <1s), you'll have to either aggressively optimize containers (which is pretty non-idiomatic with Docker containers in particular), or do away with them.

crabmusket 2y ago
Are you talking about CI or local development? Why would you run a single test in CI? And why would a container add 10+ seconds to a local task?
- necovek 2y ago
  I am talking about either, because the GP post was about "containerizing a build environment": you need your project built to either run it in CI or locally. Why would it be slow? It needs to be rebuilt? (on a fast moving project with mid-sized or large team, you'll get dependency or Dockerfile changes frequently) It needs to restart a bunch of dependent services? Container itself is slow to initialize? Caching of Docker layers is tricky, silly (you re-arrange a single command line and poof, it's invalidated, including all the layers after) and hard to make the most of. If you can't get a single test running in <1s, you are never going to get a full test suite running in a couple of seconds, and never be able to do an urgent deploy in <30s.
akdev1l 2y ago
> I've rarely seen a feedback loop with containers that's not longer than 10s only due to containerization itself Sounds like a skill issue tbh. `time podman run —-rm -it fedora:latest echo hello` will return in a few milliseconds, whatever delay you are complaining about would be from the application running in the container. Lastly containers != docker.