-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for git repositories in the 'includes' directive. #1063
Conversation
@@ -63,7 +63,19 @@ function make_parse_info_file($makefile, $parsed = TRUE, $makefile_options = arr | |||
else { | |||
make_error('BUILD_ERROR', dt("Include file missing: !include", array('!include' => $include))); | |||
} | |||
} | |||
} elseif(!empty($include) && is_array($include)) { | |||
if($include['download']['type'] = 'git'){ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
According to Drupal and Drush standards elseif
should be on a new row and be followed by a space before (
.
The if
statement just below also needs a space before (
.
I think this would be an excellent addition to the |
Thanks @dickolsson for your comments! I'm working on a proper unish test so we can check that everything's in order :) |
995a1b8
to
36c3638
Compare
if ($include['download']['type'] = 'git') { | ||
$tmp_dir = make_tmp(); | ||
make_download_git($include['makefile'], $include['download']['type'], $include['download'], $tmp_dir); | ||
$makefile = $tmp_dir . '/' .$include['makefile']; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In order to meet Drupal's coding standards, please add a space before and after string concatenations.
$makefile = $tmp_dir . '/' . $include['makefile'];
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice catch! will fix! Thanks for pointing it!
+1 for this proposal and surely it will be big help for handling multiple projects. |
Makes sense to me. I'll leave it to @jhedstrom to evaluate code and test coverage and then merge |
This is an irksome limitation we've faced repeatedly. |
This idea makes sense to me. @pmatias are you still working on test coverage for this? |
e4e3ff6
to
c506f3c
Compare
Thank you all for your quick feedback! @jhedstrom I've added tests/makeIncludesGitTest.php and three new makefiles under tests/makefiles, I'm not sure if it's the right way to go, but from here it looks like it's working. Please let me know if I should change something :) Thanks! |
@pmatias the test is throwing a fatal error. Rather than redeclare the entire test class, you should be able to add the test method you created to the existing test class. Also, it would be nice to add the documentation in this issue to the drush make docs. |
88498fe
to
8f62fe5
Compare
Thanks for pointing me to the right direction, @jhedstrom!, Now it looks better. I would love to add this to the documentation, and I'll work today on the doc proposal. Thanks again :) |
projects[drupal][version] = 7.34 | ||
|
||
; Contrib Modules | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor nit-pick; to be consistent with other make files we should change this to "Contrib modules
" and remove the blank line under the comment.
98e7cb3
to
214483f
Compare
includes[platform][download][url] = "https://github.com/pmatias/drush.git" | ||
includes[platform][download][branch] = "includes-git-support" | ||
|
||
; sub platform makefile |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
More minor nit-picks; let use initial capital letter on both comments above 😄
This is starting to look really good, IMO. Looks like the tests are failing in the last commits. Might need to take a look at that... @pmatias Perhaps you could squash all commits in this PR to a single commit so that it'll be cleaner for the maintainers to merge? @jhedstrom What's the backport policy for Drush? Should we just file a separate PR once this is in to have it considered for Drush 6 as well? |
Now, the 'includes' directive supports the following sentences: includes[remote][makefile] = 'drupal.make' includes[remote][download][type] = "git" includes[remote][download][url] = "git@github.com:organisation/repository.git" ; branch could also be tag, code relays on make_download_git function includes[remote][download][branch] = "7.x" * Correcting code style according to Drupal and Drush standards, as pointed by @dickolsson * Correcting strange indentation after last fix * Correcting string concatenation as pointed out by @nbouhid
…irective * Moving test method for includes from git instead of having it on a separate class, as pointed by @jhedstrom * Standardising comments on makefiles based on @dickolsson's feedback. * Standardising comments as pointed out by @dickolsson
0bace5d
to
cfc5e1f
Compare
Mm, it looks that the other tests are randomly failing, is there any way to re run the tests without triggering them via git push? |
Yeah, the failures look random. It looks like sourceforge was down (or Travis internal DNS is having problems). I believe only project maintainers are able to re-run tests on Travis. Or can you trigger a re-run on this @pmatias: https://travis-ci.org/drush-ops/drush/builds/45025001 ? Otherwise I think the only way is to trigger with commits (but we can squash "non-sense test trigger commits" before merge later). |
7e83140
to
bc3ee94
Compare
…repository feature
bc3ee94
to
5e85738
Compare
download: | ||
type: "git" | ||
url: "git@github.com:organisation/repository.git" | ||
# Branch could be tag or revision, it relays on the standard drush git download feature. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor spelling mistake here. It should be "relies".
This looks almost good to go-- @pmatias were you still going to add this to the docs? |
@jhedstrom I've added these lines https://github.com/drush-ops/drush/pull/1063/files#diff-17ef36930e051237472b4408a91a4f27R312 |
Add support for git repositories in the 'includes' directive.
Thanks! |
Thanks for the quick response on this PR, @jhedstrom (and everyone who provided feedback) ! Thanks! |
Changes Unknown when pulling e3f6a14 on pmatias:includes-git-support into * on drush-ops:master*. |
Git support for the includes directive
Objective
Be able to retrieve makefiles from git repositories
The reason
In our company we work with multiple makefiles for hundreds of different projects, and we are currently working on a better way to organise our several dozens of makefiles. One approach that we've found to be very practical for us is the following example structure:
The problem
The only problem with this setup is that our makefiles are distributed in several private git repositories (divide and conquer: this way we can have better control on what project/patches are inside on the different types of platforms) so getting the makefiles from raw urls is off the table since it will need some kind of authentication, and we're not going to write nasty stuff to make that happen.
The solution
The 'includes' directive supports git repositories. This way, we get to assemble the main makefile the way we need it (also we get to define the core directive in the remote makefile that we want, and not the main one, giving us more control on Drupal versions).
Code proposal
With this code, drush make will support the following sentences in the makefiles:
Also, despite our reasons of needing this feature, it seems like a natural feature that 'includes' could use, since it currently supports local files, relative path local files and remote urls.
Final thoughts
The idea is to meet the requirement without going against the community standards, so if you think that we can achieve the same with another approach, or you have a different approach for the submitted code in this PR, please let me know.
Thanks!