Moved phing build tools to separate project #26

merged 2 commits into from Dec 3, 2012


None yet

3 participants

chillu commented Nov 21, 2012

See Will migrate to once approved.

Two reasons: There's a lot of cruft in the default checkout which is only really required for a handful of developers, for example the getlocalization sync targets. But more importantly because versioning becomes a hassle: The build tools are 95% the same between releases. For 2.4 we don't have any build tools set up, which complicates releases. I've added support light logic branching and a simple version_compare() statement.

One example is missing the replacements in the silverstripe_version files in the last couple of 2.4.x releases (basically all of them since we switched from SVN). Stuff like that is automated in 3.x, and it should be in 2.x as well.

I've left the 'phing phpunit' and 'phing behat' tasks in their original place, since they're useful for any community dev.

The whole 'dependent-modules' and 'new-project' logic has been removed from the new module, in favour of composer. The build system could take more advantage of composer metadata, but its a start.

Also submitted a pull request to fix the docs: silverstripe/silverstripe-framework#962

Once this is merged, I'll check the release docs on the bert wiki, TeamCity builds, create a silverstripe/silverstripe-buildtools repo and according packagist package.

sminnee commented Dec 3, 2012

This seems fine to me; if @hafriedlander doesn't have any objection I say we merge it.

sminnee commented Dec 3, 2012

Ingo, are you aware that is an existing repository? Most of the content of that repo is rendered obsolete by Composer but it does raise the point that buildtools would be usefully designed such that it was a collection of tools that could be used for other projects. For example:

  • It could be used to build an archive of custom SilverStripe projects
  • It could be used to integration other modules with getlocalization

I'd be more comfortable with the split out if we were seeing this as a decoupling of the buildtools, rather than merely sharding a tightly coupled build.xml file into a separate repo.

It doesn't need to be done before the split; those could be issues created on the new repo; but it's good to set a clear picture of where the repo is heading.


Yeah, seems fine to me too. Should we make the buildtools module a "requirements-dev" requirement? Also, I think we can trash new-project completely now - was just a hacked up tool until composer worked.

chillu commented Dec 3, 2012

From what I can tell, we can completely replace that other repo, maybe add back some help text from silverstripe-archive/silverstripe-buildtools@4fdac3a.

Do you see any value in keeping the bootstrap(3).php stuff around in there - is it used in internal builds?
We have those files in the core branches, and have been happily running phpunit projects off those for a while.

@chillu chillu merged commit 5c1a16f into silverstripe:3.0 Dec 3, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment