Open
Description
Is it possible to disable the /workspace cache of a coder build with envbuilder.
Even after restart work spaces it caches to old commit
#1: 📦 Cloning https://bitbucket.org/lorem/repo.git to /workspaces/ipsum..
#1: 👤 Using no authentication!
#1: 📦 The repository already exists! [672.333µs]
Metadata
Metadata
Assignees
Labels
No labels
Activity
johnstcn commentedon Aug 3, 2024
What should envbuilder do in this case if the repository contains uncommitted changes?
Should it still fetch changes from the remote?
megla-tlanghorst commentedon Aug 7, 2024
Couldn't it check for local changes? I had this when the devcontainer build failed and I fixed it in the repo, but I had to destroy the workspace because I couldn't update it easily obviously.
Basically just:
Maybe even just as an option
[-]envbuilder caches repo [/-][+]envbuilder: fetch upstream changes from repo if local copy is not dirty[/+]mafredri commentedon Aug 8, 2024
@megla-tlanghorst would the
--remote-repo-build-mode
option we recently introduced cover your use-case?Automatically updating the users repo is an interesting proposition too, though. There are some caveats though:
megla-tlanghorst commentedon Aug 8, 2024
Maybe, that's what I'm currently testing.
johnstcn commentedon Aug 8, 2024
Alternative possibility is add -> stash -> pull -> unstash. This does run the risk of users being left to clean up a nasty merge conflict though.
johnstcn commentedon Sep 13, 2024
Parking this for now due to some open questions:
fetch
andcheckout
versuspull --ff-only
? The former seems safer to me. Or do westash
->pull
->unstash
?ENVBUILDER_GIT_URL
?mafredri commentedon Sep 13, 2024
@johnstcn I think we should only operate on a clean repository with the default/configured branch checked out. If a user has local changes or a custom branch checked out then we must assume they were in the middle of doing something, and we can't risk removing their anchor, or worse, introduce merge conflicts.
We can instead add a destructive option which simply overwrites the whole repository (in its simplest form: delete + new checkout). This is for anyone who wants the workspaces to be ephemeral, but still uses a permanent storage for some reason.
johnstcn commentedon Sep 13, 2024
@mafredri One other scenario I could imagine is that a different git repo is cloned to the path into which we wish to clone. Do you think it's sufficient to check that the URL of the remote "origin" is the same as
ENVBUILDER_GIT_URL
(after parsing / normalization)?mafredri commentedon Sep 13, 2024
If I'm understanding you correct, I'd say yeah we want to do that. Essentially we want to check that the remote of the currently checked out branch matches that of envbuilder git URL (name, like "origin" shouldn't matter). If the envbuilder git URL specifies a branch, the currently checked out branch should match as well (match by the remote tracking branch, not necessarily local name). Assuming the repo is clean1 too, we can update.
1 Clean repo means no changes to tracked files and no staged changes. Untracked files should be safe to ignore as I think users wouldn't want those to block the update in most cases.
5 remaining items