3 ms·
>It will run your builds on the same disk image which are kept persistent between job runs Unless I have misunderstood, this sounds like a recipe for a nightma
by c7DJTLrn 6y ago
>It will run your builds on the same disk image which are kept persistent between job runs
Unless I have misunderstood, this sounds like a recipe for a nightmare. One of the benefits of an ephemeral CI system is that you know any dependencies you install won't pollute future builds.
- deleted 6y ago[deleted]
- thinkafterbef 6y agoModern package managers have already made sure this doesn't happen. Take npm for example, it only takes what is definied in package-lock.json, everything you installed in the past is cleaned up automatically. In fact, self hosted CI builders solely rely on such guarantee provided by package managers to produce correct builds.
- c7DJTLrn 6y agoPackage managers that come as part of a programming language are only part of the story. What about system packages? I'm talking about shared objects, headers, those sorts of things that you might install with apt or dnf. This is what trips people up the most when trying to build software, especially C/C++ projects.
- thinkafterbef 6y agoNormally you install C/C++ libraries via system package manager like apt, or via your own script. So in deltaci's config it will look like this: steps: - run: apt install -y libxyz-1.1 when: first_run or steps: - run: wget http://libxyz-1.1.tar.gz && tar zxvf libxyz-1.1.tar.gz && cd libxyz-1.1 && make && make install when: first_run In our past experience, this is one of downside of self-hosted runners as you have to remove libxyz-1.1 manually. this is actually one of the reason why we wanted to make DeltaCI. It's currently solved like this, as soon as you replace libxyz-1.1 with libxyz-1.2, our system notice that the config has changed, it will execute it from a fresh environment instead trying to reuse previous building agent.