civicrm / civicrm-buildkit

A collection of tools for developing and testing CiviCRM.
https://docs.civicrm.org/dev/en/latest/tools/buildkit/
51 stars 91 forks source link

civibuild keeps showing help #234

Closed AbdealiLoKo closed 8 years ago

AbdealiLoKo commented 8 years ago

I'm not quite sure if this is a docs issue or a civibuild issue.

I installed buildkit and now tried to run civibuild using the command here and it just keeps showing me the -h info again and again. I'm running: $ civibuild create dmaster --url http://localhost:8001 --admin-pass s3cr3t

ajk@ajk-ThinkPad-R60:~/Documents/civi$ civibuild create dmaster --url http://dmaster.localhost --admin-pass 111
Common options:
  <build-name>        The name of the sub-directory to build
  <ms-id>             The unique id for a site within a multisite build

Syntax: civibuild create    <build-name>[/<ms-id>] [options]
Syntax: civibuild download  <build-name>           [options]
Syntax: civibuild install   <build-name>[/<ms-id>] [options]
Syntax: civibuild reinstall <build-name>[/<ms-id>] [options]
Description: Download and/or install the application
  --type <type>       The name of the download/install scripts. (If omitted, assume <build-name>) [Optional]
  --web-root <path>   The full path to the website root. [Default: /home/ajk/buildkit/build/<build-name>]
  --civi-ver <ver>    The branch or tag of CiviCRM desired (master, 4.4, 4.3, 4.3.0, etc) [Optional]
  --cms-ver <ver>     The release of the CMS desired [Optional]

  --url <url>         The public URL of the site
  --title <title>     The title of the site
  --admin-user        Name of the CMS's administrative user
  --admin-pass        Password for the CMS's administrative user
  --admin-email       Email of the CMS's administrative user
  --demo-user         Name of the CMS's demo user
  --demo-pass         Password for the CMS's demo user
  --demo-email        Email of the CMS's demo user

  --force             If necessary, destroy pre-existing files/directories/DBs
                      (For "reinstall", "--force" is implicit.)

Syntax: civibuild list
Description: Display a list of build-names found in the build directory. 

Syntax: civibuild edit <build-name>[/<ms-id>]
Description: Edit the <build-dir>/<build-name>[.<ms-id>].sh config file

Syntax: civibuild show <build-name>[/<ms-id>] [options]
Description: Show key details about the build
  --html <dir>        A new HTML dir which will report build status in detail
  --new-scan <file>   A new JSON file which summarizes the git structure
  --last-scan <file>  An existing JSON file which summarizes the old git structure
  --full              Show all build options declared

Syntax: civibuild snapshots
Description: List available snapshots

Syntax: civibuild snapshot <build-name>[/<ms-id>] [options]
Syntax: civibuild restore  <build-name>[/<ms-id>] [options]
Description: Create or restore a snapshot of the CMS+CRM DBs
  --snapshot <name>      The name of the snapshot subdirectory. (If omitted, assume <build-name>) [Optional]
  --cms-sql <sql-file>   The path to a SQL backup of the CMS DB [Optional]
  --no-cms               Skip resetting the CMS DB [Optional]
  --civi-sql <sql-file>  The path to a SQL backup of the CiviCRM DB [Optional]
  --no-civi              Skip resetting the CiviCRM DB [Optional]

Syntax: civibuild clone-create <build-name>[/<ms-id>] [options] [snapshot-options]
Syntax: civibuild clone-show <build-name>[/<ms-id>] [options]
Syntax: civibuild clone-destroy <build-name>[/<ms-id>] [options]
Description: Create, export, or destroy a DB clone based on a snapshot
  --clone-id <name>      The name of the specific clone. [Required for clone-create, clone-show]
  --force                If necessary, destroy pre-existing files/directories/DBs

Syntax: civibuild restore-all
Description: Restore *all* HTTP/DB services from their respective snapshots

Syntax: civibuild upgrade-test <build-name>[/<ms-id>] <sql-bz2-files>...
Description: Loads each DB snapshot and runs the current upgrade logic
  <sql-bz2-files>        One or more *.sql.bz2 files.
                         [Default path: /home/ajk/buildkit/vendor/civicrm/upgrade-test/databases/]

Syntax: civibuild destroy <build-name>
Description: Destroy all data about a particular build
AbdealiLoKo commented 8 years ago

Seems that the reason for this is the build folder is empty. In civibuild_detect_site_name() when we check compgen -G $BLDDIR/*.sh it returns nothing making it return without the SITE_NAME

ginkgomzd commented 8 years ago

I don't think that dmaster is a valid build type. Type is only optional when the buildname matches a build type. Sorry, I didn't take an in-depth look but if that doesn't fix it, let us know.

totten commented 8 years ago

dmaster is an alias (civibuild.md, civibuild.aliases.sh). It's equivalent to saying:

civibuild create dmaster --type drupal-demo --civi-ver master --title "CiviCRM Sandbox on Drupal" ...
totten commented 8 years ago

See: https://github.com/civicrm/civicrm-buildkit/pull/235

ginkgomzd commented 8 years ago

ah yeah... I think #235 is a good fix and I should go back to the drawing board. I was striving for more flexible argument passing. I should create some tests for the cases I would like supported. I can't take the time right now because it is the last day of my travels, so I suggest merging your PR to resolve the regression. I should also do some more research on parameter parsing. This is what I'm going for e.g. civibuild --web-root /var/www/mysite create --type drupal-demo mysite But I think "drupal-demo" would get interpreted as the site name currently. It seems foolish now to think that validation would get me there. Create is probably the action that most needs the flexibility. I won't write down all the thoughts that just ran through my head, but I think this might be the best one...to break up the help text and give action specific help. I think the key here and for the objective of more flexible parameters is the same... to modularize it into different commands so that: civibuild create... is dispatched to a "civibuild-create" internal command. This way, there would be only one un-named parameter which would also be required. Currently, we parse unnamed params before the named params. I think having only one required unnamed param would allow a single params parse loop, which makes it easy to separate unnamed params from named-param values. Maybe there is still an easy way I'm no thinking of to separate unnamed params from values.

AbdealiLoKo commented 8 years ago

@totten @ginkgomzd Thanks for the replies

We should change the docs at https://github.com/civicrm/civicrm-buildkit/blob/master/doc/civibuild.md then ?

AbdealiLoKo commented 8 years ago

Awesome. The latest PRs got it working fine. Closing this now.