wunderio / build.sh Goto Github PK
View Code? Open in Web Editor NEWbuild.sh is a script for managing drush make based projects
License: GNU General Public License v3.0
build.sh is a script for managing drush make based projects
License: GNU General Public License v3.0
Create a builtin command that can sync database and files between environments with appropriate sanitization / cleanup and can install, enable and configure environment specific modules.
Right now there's no way to inspect what happened if the results of the build process are not as expected.
Logging the output would help a great deal.
Since drupal 8 gives problems if you have some file structure from a previous installation, when you try to upload files in a new installation with old files dir, let's just clear it out upon site-install (could be polite to ask for permission)
To reproduce the error:
Install drupal,
Upload a file,
You'll have a subdirectory in files, 2016-01.
Install drupal again,
Try to upload a file,
Get a weird error, no output in nginx, php-fpm, no real explanation in Drupal's own watchdog, check permissions, they are ok, still no go, but then do a rm -r 2016-01
and upload agin
and smile
and think that other people will crash in the same issue, and that build.sh could help us avoid that
So that make
could be replaced with direct call to composer
Make process should fail if there are any development modules present in makefile.
After the latest commit to the develop branch a618032 I'm getting this error while trying to build:
** BUILD ERROR: [Errno 2] No such file or directory: '/vagrant/drupal/current_bak'
Running the install command returns this error
** BUILD ERROR: execv() arg 2 must contain only strings
Current version is 7.37 and in makefile its 7.34.
There's quite a few old branches, many of which have been merged.
https://github.com/wunderkraut/build.sh/branches/all
It'd be good to review and delete those which are no longer needed.
Create a builtin command that can read environment configs and restart / reload services.
We have a project where build.sh is set to copy features etc. on build update. The newest version of build.sh fails since it packs the old build and then unpacks it and uses the old code. Using link instead of copy works for now, but this is something that should be fixed.
Often there is the need to run some arbitary drush commands on the installation so it would be nice to have a drush command (like the existing shell-command) that could be used to run drush commands without the need to define the path to drupal installation, like it's now required if using shell-command to run drush.
./build.sh update failed on me for a specific reason, and when I fixed the issue that caused the failed build, I got stuck with this error:
** BUILD NOTICE: Finalizing new build ** BUILD ERROR: [Errno 39] Directory not empty
Which had to be resolved by rm -rf current_bak/
before I was able to run build.sh update again. Not fun in the heat of a deployment moment.
rmtree seems to try to follow symlic and tries to remove eg. files/ resulting either data loss or build error with "operation not permitted.'
If shell command can not be executed build process continues and may cause build to die later on process or finish successfully when actually something went wrong . That makes it harder to debug. This should be changed so that build fails with message of command that failed.
I'm not sure if this is already possible or not, but I'll ask how it would be possible.
I would like to use build.sh
for building my local setup for lets say Commerce Kickstart: https://github.com/commerceguys/commerce_kickstart
You see that there are multiple make files and the repository and it's compatible with the Drupal.org packaging, but I have no idea how this could be buildable with build.sh
tool.
Any thoughts? Do we need a feature for this?
When there is just some small changes to the custom code, features or theme there is no need to run the whole make process to get those changes in production.
Implementing either a 'hotfix' command that would only copy the code/* folders to their respective places under current build dir or taking into use the makefile hash check when deciding if the full build is necessary would be nice.
To make this properly open sourced let's add license for this project.
My site.make
file:
core = 8.0
projects[drupal][version] = 8.0.0
When installing using ./build.sh new
, I get the following error:
Starting Drupal installation. This takes a while. Consider using the --notify global option. [ok]
exception 'Drupal\Core\Installer\Exception\InstallerException' with message 'Default settings file: The default settings file does not exist. [error]
The Drupal installer requires that the <em class="placeholder">./sites/default/default.settings.php</em> file not be modified in any way from the
original download.' in /Users/myuser/Sites/mysite/drupal/core/includes/install.core.inc:2173
Stack trace:
#0 /Users/myuser/Sites/mysite/drupal/core/includes/install.core.inc(1014): install_display_requirements(Array, Array)
#1 /Users/myuser/Sites/mysite/drupal/core/includes/install.core.inc(648): install_verify_requirements(Array)
#2 /Users/myuser/Sites/mysite/drupal/core/includes/install.core.inc(526): install_run_task(Array, Array)
#3 /Users/myuser/Sites/mysite/drupal/core/includes/install.core.inc(116): install_run_tasks(Array)
#4 /Users/myuser/.composer/vendor/drush/drush/includes/drush.inc(721): install_drupal(Object(Composer\Autoload\ClassLoader), Array)
#5 /Users/myuser/.composer/vendor/drush/drush/includes/drush.inc(706): drush_call_user_func_array('install_drupal', Array)
#6 /Users/myuser/.composer/vendor/drush/drush/commands/core/drupal/site_install.inc(78): drush_op('install_drupal',
Object(Composer\Autoload\ClassLoader), Array)
#7 /Users/myuser/.composer/vendor/drush/drush/commands/core/site_install.drush.inc(289): drush_core_site_install_version('minimal', Array)
#8 [internal function]: drush_core_site_install('minimal', 'install_configu...')
#9 /Users/myuser/.composer/vendor/drush/drush/includes/command.inc(364): call_user_func_array('drush_core_site...', Array)
#10 /Users/myuser/.composer/vendor/drush/drush/includes/command.inc(215): _drush_invoke_hooks(Array, Array)
#11 [internal function]: drush_command('minimal', 'install_configu...')
#12 /Users/myuser/.composer/vendor/drush/drush/includes/command.inc(183): call_user_func_array('drush_command', Array)
#13 /Users/myuser/.composer/vendor/drush/drush/lib/Drush/Boot/BaseBoot.php(65): drush_dispatch(Array)
#14 /Users/myuser/.composer/vendor/drush/drush/includes/preflight.inc(64): Drush\Boot\BaseBoot->bootstrap_and_dispatch()
#15 /Users/myuser/.composer/vendor/drush/drush/drush.php(12): drush_main()
I believe this is due to the fact that default.settings.php
is removed in def make
.
Now that Drupal is moving away from drush make and towards a composer build workflow, it would be nice if the build script can choose whether people want to build their Drupal site with composer or drush make.
With atomic deployments webroot link might not be relative to some files outside of it in correspondence to releases folder.
The build script itself should be fit for both d7 and d8, there are just some build examples that are drupal version specific.
The repo should be reorganized so that both d7 and d8 exxamples could coexcist on the same branch.
Build.sh takes backups, but it would be nice also to have ./build.sh restore pathtobackup.tgz
feature.
If files dir is not included into project or synced before build the build process will fail with erro "cannot link, source does not exist.'
Can we perhaps have a way to specify composer options from site.yml
like so:
Or even make own section for composer options:
dev:
composer-options:
require-dev: true
Practical example would be to define which environments needs --no-dev
and which not. Now it seems to be hardcoded.
The site.yml should be separated to two files:
With this configuration we could then have commands.yml to be updated from upstream when we do some updates.
Running build.sh outside of vagrant box while running the stack in the vagrant box doesn't work. For example Nginx just returns file not found.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.