Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Prebuilds - Speed up workspaces creation for large repositories #9611

Closed as not planned
@ggjulio

Description

@ggjulio

CDEs with aPrebuilds 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 throughstartup 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 themain/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:

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions


      [8]ページ先頭

      ©2009-2025 Movatter.jp