… the env.
unit test running.
This adds the notion of hierarchy to builds within a release. If a build has a symlink named "parent" in its directory, then it will inherit barclamp metadata from the build that the parent symlink points to. This patch also adds more paranoia when doing builds using a git managed build cache.
This allows sync to just sync barclamps if the top-level Crowbar repo is dirty, and has pull-requestd-prep only deal with barclamps for now.
remotes, not after.
We weren't grabbing them properly when clone_and_sync_barclamp did not clone a barclamp.
This patch migrates dev from repo metadata v.1 to v.2. The following big changes are present: * Uniform remote handling across all Crowbar repositories. The dev tool now enforces that git remotes across all Corwbar repositories point at the same thing. All remote handling should be performed via ./dev remote commands, and not git remote commands. * Remotes are priority sorted. Each remote managed via dev has an assigned priority from 1 to 100, the lower the number the higher the priority. The remote you cloned Crowbar from (previously known as "origin") has priority 5, the remote you back things up to (your personal remote) has priority 95, and everything else defaults to priority 50. Remote priorities can be changed on the fly -- see README.dev-and-workflow for more information. * dev assures that tracking branches point at the proper remotes. Local branches that exist in remotes will be configured to act as tracking branches pointing at the highest priority remote that has that branch. Any time you update a remote (by adding, removing, or changing priority) or run a ./dev fetch the tracking branches will be updated. * dev does not have a hardcoded dependency on dellcloudedge. You can clone and setup from any crowbar repository, and dev will handle making sure that all the barclamps are cloned from the same location. * You can push and pull from any remote that comes from github. By default, pull-requests-prep and pull-requests-gen will target the highest-priority remote. You can change which remote you are targeting with the --to parameter. * You can easily merge changes from any configured remote unto your local branches. By default, sync will pull in changes from the highest priority remote. You can change the remote that will be merged in with your local branches using the --from flag. * Submodules are a thing of the past. The multiple branches with submodules model of tracking barclamp dependencies for each build was fine when we only had 1 release with a few builds, but the overhead of keeping everything synchronized became too fragile, leading to easily losing commits. Instead, all that tracking information (along with per-build build system differences) has been migrated into the releases subdirectory of master. The branching structure for barclamps is unchanged, and the tracking info for each build will pull in either the head of a release-specific branch in the barclamps, a specific tag, or a specific commit.