Page MenuHomePhabricator

Make WorkingCopy resources more powerful and flexible
Open, NormalPublic

Description

WorkingCopy resources have a bare minimum featureset right now. Some things they should have soon include:

  • Support for Mercurial and Subversion.
  • Better support for submodules.
  • Support for different reset/clean levels. Not sure how many we need, but:
    • Upstream wants basically no cleaning, although git clean -df to get rid of untracked files is fine. We have caches in ignored files.
    • It's reasonable to want/expect to start with a totally clean working copy, roughly git clean -dfx to get rid of ignored files too. This should probably be the default level.
    • We could also support a "one-time" level where the entire working copy is cloned every time.
    • OK to put this stuff as a preference on the WorkingCopy resource?

Event Timeline

epriestley raised the priority of this task from to Normal.
epriestley updated the task description. (Show Details)
epriestley added a project: Drydock.
epriestley moved this task to v2 on the Drydock board.
epriestley added subscribers: epriestley, hach-que.

I'm generally imagining we'll get something like this in the Blueprint configuration:

Submodules: [ Yes! (Slower)         V ]
            [ Sort of?                ]
            [ No (Faster)             ]
          
     Clean: [ Everything! (Slower)  V ]
            [ Some stuff?             ]
            [ Nothing (Faster)        ]

...where full submodule support / full clean are the defaults.

I don't know if 3 levels is the right number of options for either of these. Maybe submodules only have "yes" or "no", or maybe running the commands costs so little in any reasonable setup that we just always do it. On the other hand, maybe there are 4 or more meaningful levels of cleaning available.

There could also be a "Complete Reclone" clean option which destroys the resource after a single use, or this could maybe be an option elsewhere ("[X] These resources are one-time use."). I suspect the tradeoffs by reusing resources are highly desirable for most reasonable workflows, but if you have a many-minutes-long build process anyway maybe shaving startup time from 2 minutes to 2 seconds doesn't really matter.

if you have a many-minutes-long build process anyway maybe shaving startup time from 2 minutes to 2 seconds doesn't really matter

that's the boat i'm in, we also do things like generate a .deb from the build output, so eliminating any possibility of cruft from previous working copies is important to us.

@epriestley : is making /var/drydock non hard written or just documented part of this ??

eadler added a project: Restricted Project.Aug 5 2016, 5:24 PM