Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for incremental builds #304

Open
rarguello opened this issue Jan 27, 2019 · 8 comments
Open

Add support for incremental builds #304

rarguello opened this issue Jan 27, 2019 · 8 comments
Labels

Comments

@rarguello
Copy link

No description provided.

@frenzymadness
Copy link
Member

Could you please provide more info? What do you mean by incremental builds and why is this important?

@torsava
Copy link
Member

torsava commented Mar 19, 2019

@omron93 Do we use incremental builds in other containers?

@pkubatrh
Copy link
Member

@torsava soon in nodejs: sclorg/s2i-nodejs-container#201

@torsava
Copy link
Member

torsava commented Mar 19, 2019

@pkubatrh Ah, thanks. I thought the incremental build feature of s2i was kinda buggy/unfinished. So I would probably wait to see how it works out for nodejs, see if they can work out the kinks before implementing it here.

@torsava torsava added enhancement P3 Priority 3 labels Mar 19, 2019
@omron93
Copy link
Contributor

omron93 commented Mar 23, 2019

@pkubatrh @torsava https://github.com/sclorg/golang-container supports incremental builds for some time already. I'm not aware of any problems with it. @jcajka Are you?

@jtratner
Copy link

I think this would really help adoption. Right now, using s2i means waiting for a really slow build vs. a Dockerfile where requirements.txt would be cached.

@wjhrdy
Copy link

wjhrdy commented Aug 20, 2021

I just found this article about how to make incremental builds work using s2i python container. https://developpaper.com/using-s2i-to-build-images-from-source-code/

@frenzymadness
Copy link
Member

So, If I understand it correctly from the node and go containers, it should work for Python container like this:

  • Users prepare their own Dockerfile, where they call the save-artifacts script which basically creates a tarball from the main virtual environment with all app dependencies already installed.
  • Then, during a second build, if the tarball is provided in /tmp/artifacts, it's extracted to the original location (virtual environment).
  • Assemble script still tries to install all dependencies but because some or ideally all of them are already there, the second build is much faster.

Is that correct?

I don't use s2i because it does not support podman so is there any significant difference when s2i is used and a user does not have to prepare its own dockerfile manually?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: No status
Development

No branches or pull requests

7 participants