Skip to content

Prebuilds - Speed up workspaces creation for large repositories #9611

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

Closed
ggjulio opened this issue Sep 10, 2023 · 2 comments
Closed

Prebuilds - Speed up workspaces creation for large repositories #9611

ggjulio opened this issue Sep 10, 2023 · 2 comments

Comments

@ggjulio
Copy link
Contributor

ggjulio commented Sep 10, 2023

CDEs with a Prebuilds feature provides a way to use their workspaces as short-lived/ephemeral environnement on large/complex repositories.

Coder's closest way of achieving something similar is through startup scripts, which is fine for small code base.
But it doesn't works well for large repositories.

As far as I know, there is currently 3 CDEs implementing it:

It usually works by building the main branches, (let's say the main/master branch)
The "output" is stored and then any users can get a fresh workspace from it.
Prebuilds are linked to the commit hash they have been built with.

Theses fresh workspaces may contain:

  • Object / bytecode files, final binaries / artefacts
  • Any dependencies such as libraries/modules, container images, etc
  • Debug related files -> symbols/map files, etc...
  • Indexes/Caches from developer's tools
  • ?

From the 3 CDE above, a prebuild may be triggered via:

  • push/merge
  • Scheduled
  • Manual trigger
  • On file change (like devcontainer.json)
  • Every N commits
  • ?

Why Prebuilds are worth to be implemented

The inability of using short lived/ephemeral workspaces on large repos have several impacts :

  • Long lived workspaces may drift and result in "works on my machine" issues.
  • Context switching takes time (reviewing PR, hotfix an issue, etc)
  • ?

Large companies tend to have large and complex repositories.
Implementing it may help them significantly reduce time spent on the two issues above.

Could also:

  • Reduce resources consumption peaks (avoiding N builds by N developers when their workspaces starts)
  • ?

Implementation ?

All CDEs above currently supports only one isolation model and/or infrastructure.
Coder doesn't make any assumptions on neither of the infra or isolation model.
Which could make it hard for coder to implement such a feature.

What are you thoughts about it ?


Resources:

@ammario
Copy link
Member

ammario commented Apr 22, 2024

Tackling this issue here: #5325

@ammario ammario closed this as not planned Won't fix, can't repro, duplicate, stale Apr 22, 2024
@bpmct
Copy link
Member

bpmct commented Sep 27, 2024

Hey folks - added some updates to #5325!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants