This issue is a child of #61

I anticipate that one of the biggest difficulties in supporting this project across different CI services (Circle, Travis, Jenkins, GitLab CI) as well as making alternate versions of the repo (WordPress, Drupal Commerce, Drupal 7, etc) will be keeping global variable conventions consistent. We spend more lines in circle.yml on environmental variables than we do on any other section.

I just came across a mechanism for setting environmental variables in CircleCI that might help with this problem. This example repo from CircleCI concatenates on to ~/.circlerc in order to add environmental variables.

That example repo is using that mechanism as an alternative to the CircleCI UI for setting private variables. I am suggesting we consider using it for the management of non-private variables (and maybe private ones too). We could have a file in this repo containing something like

export BRANCH=$(echo $CIRCLE_BRANCH | grep -v '^\(master\|[0-9]\+.x\)$')
export PR_ENV=${BRANCH:+pr-$BRANCH}
export CIRCLE_ENV=ci-$CIRCLE_BUILD_NUM
export DEFAULT_ENV=$(echo ${PR_ENV:-$CIRCLE_ENV} | tr '[:upper:]' '[:lower:]' | sed 's/[^0-9a-z-]//g' | cut -c -11 | sed 's/-$//')
export TERMINUS_ENV=${TERMINUS_ENV:-$DEFAULT_ENV}
export NOTIFY='scripts/github/add-commit-comment {project} {sha} "Created multidev environment [{site}#{env}]({dashboard-url})." {site-url}'

I might just try a PR to validate that this would even work.

It would be good if the default build scripts could save the resulting build as an archive in CircleCI. This gives teams an extra layer of security (knowing in the future what exactly was deployed), and can help with debugging where a developer can download the exact build that was deployed.

At first, I thought this wasn't needed as git is used for the deployment. However, git push --force -q pantheon temp-work-ci-1:master is used, which means that a force push could technically delete the history and prior builds.

In testing out the instructions for the Pull Request Workflow, under the Create a Pantheon Site section, I believe there is a missing command.

I was using Terminus version 1.2.1 and when creating the site it defaults to SFTP mode. The immediate next instructions are for a series of Git commands including a push. This will fail unless the site has been set to Git mode.

checkout https://www.drupal.org/project/simple_block

How do you associate the repository with the pantheon site.

After installing terminus and composer, and creating machine tokens for Github and CircleCI, I am getting the following error with terminus build:project:create d8 [my-project-name] :

[error] GitHub error: Bad credentials. Http status code: 401

I have deleted and regenerated my Github tokens. Is there a way to confirm that the export of my github token was successful? Is there a step that I have missed? Any help is greatly appreciated.

Consider making the circleci portion of the project orbs. See http://go.circleci.com/X2G0faM0k000H15h3022ZX0

Copied the repository.
Tried the first build.
But fails at terminus build-env:delete:ci -n "$TERMINUS_SITE" --keep=2 --yes
Asks for password. I am using my pantheon site as $TERMINUS_SITE.
Here is the screen-shot:
http://screenshotlink.ru/0f3abcb62a1ac6bbe58358df5816735e.png

I would like to remove the deploy_product key from pantheon.yml. This section was added to accommodate the use case of a custom upstream not committing a vendor directory and relying on the site spin-up process to do the composer install.

https://github.com/pantheon-systems/example-drops-8-composer/blob/master/pantheon.yml#L5

I don't know if any upstream users ever did this and I would not recommend anyone do it going forward. @greg-1-anderson any objection to removing?

Currently I have a public repo with a custom upstream at https://github.com/marklabrecque/test-upstream and am trying to build a Pantheon CI project leveraging it. It is quite literally an unchanged fork from https://github.com/pantheon-systems/example-drops-8-composer at this point, but it fails on running the following command:

`terminus build:project:create marklabrecque/test-upstream

First it asks me for my Github and CircleCI tokens, which appears to work, but then I get the following output:

[notice] Create GitHub project fcv-testing-testing from marklabrecque/test-upstream
[notice] Call GitHub API: user
[notice] Creating project and resolving dependencies.
[notice] Running composer create-project --working-dir=/private/var/folders/c9/4s2vb1x11_s3t5w90mdb0vg1j4l4bd/T/local-siteXLxl8Y marklabrecque/test-upstream fcv-testing-testing -n

[InvalidArgumentException]
Could not find package marklabrecque/test-upstream with stability stable.

create-project [-s|--stability STABILITY] [--prefer-source] [--prefer-dist] [--repository REPOSITORY] [--repository-url REPOSITORY-URL] [--dev] [--no-dev] [--no-custom-installers] [--no-scripts] [--no-progress] [--no-secure-http] [--keep-vcs] [--no-install] [--ignore-platform-reqs] [--] [] [] []

[error] Command composer create-project --working-dir=/private/var/folders/c9/4s2vb1x11_s3t5w90mdb0vg1j4l4bd/T/local-siteXLxl8Y marklabrecque/test-upstream fcv-testing-testing -n failed with exit code 1 `

I have verified that the repo is public and that my Github access token is valid.

I ran through the build tools documentation, and want to install a module that depends on PHP 7.1 or greater. I see that the platform version in composer.json is set to "7.0.8":

"platform": {
            "php": "7.0.8"
        }

However, the pantheon.yml file has PHP 7.2:

php_version: 7.2

When I try to install the module that depends on 7.1, I get:

[InvalidArgumentException]
Package drupal/apigee_edge at version has a PHP requirement incompatible with your PHP version (7.0.8)

Questions:

1. Should this composer project have the PHP version set to 7.0.8? Is there a reason for this?
2. Why does the composer file require 7.0, but the Pantheon site runs on 7.2?
3. How can I install a module that needs 7.1 or above? I am assuming I should change the composer.json platform requirement and pantheon.yml to be 7.1.

Here is a break-out issue from #61 (comment)

In that comment @greg-1-anderson questioned if build-assets, which wraps composer install is needed. Could we instead just call composer install and expect project to have hooked into that process?

I think we should. Our composer.json already has additional commands running in post-install-cmd

    "post-install-cmd": [
      "@drupal-scaffold",
      "DrupalProject\\composer\\ScriptHandler::createRequiredFiles"
    ],

I suggest we deprecate build-assets and only run composer install. For pre-existing sites, the Build Plugin will need to check if build-assets exists.

Update drupal core to 8.6.2 to address SA-CORE-2018-006

In a couple cases, the .gitignore file points to web/sites/*/[etc], but for ignoring the files directory, it points to web/sites/default/files -- I understand that multisite isn't supported so the * wildcard is irrelevant, but still, it seems like an unnecessary customization of the .gitignore file included in vanilla drupal (from drupal-composer/drupal-project).

Either way, I think it should probably be consistent -- obviously, I vote for changing the files dir pointer to web/sites/*/files :)
https://github.com/pantheon-systems/example-drops-8-composer/blob/master/.gitignore#L54

(Yes, yes I am doing a full comparison of vanilla drupal codebase (via drupal-composer/drupal-project) versus pantheon-systems/example-drops-8-composer :) )

I don't see a way to specify that a new repository should be private. While at the initial phase it's not as if there's private code, it makes it harder to use the "real" name for a project where the project name shouldn't be exposed to the public, even for a short time.

We're using Circle + a forked version of example-drops-8-composer (Forked on Sept 13th)

d468d61

What I did

• Create a git branch locally from master "feature-x"
• Push to github
• create a GH Pull request

What happened
This triggers off the workflow, but the multidev environment it isn't named after the branch. We get ci-102 or pr-10 or whatever the # of the ID in github.

What I expected
I was expecting the PR to create a multi-dev call "feature-x-project.pantheonsite.io"

We've tried editing the CircleCI "Advanced Settings" with various settings...

• Only build pull requests = ON

This removes the ci-102 builds but we still don't get the multidev environments named after the PR's branch.

Possibly related: We noticed when we "merge + delete" pull requests in github the related pantheon multidev is not deleted automated. We're cleaning them up manually right now.

Questions

• Am I right to assume the multidev should be named after the branch?
• There was a release a day after our build was forked. Do you think we need to move to that commit?
• What are the expected CircleCI advanced settings? (Current settings copied here for reference)

GitHub Status updates

By default, we update the status of every pushed commit with GitHub's status API. If you'd like to turn this off (if, for example, this is conflicting with another service), you can do so below.

• On
• Off

Build forked pull requests

Run builds for pull requests from forks. CircleCI will automatically update the commit status shown on GitHub's pull request page.

• On
• Off

Pass secrets to builds from forked pull requests

Run builds for fork pull request changes with this project's configuration, environment variables, and secrets.

There are serious security concerns with this setting (see the documentation for details.) If you have SSH keys, sensitive env vars or AWS credentials stored in your project settings and untrusted forks can make pull requests against your repo, then this option isn't for you!

• On
• Off

Only build pull requests

By default, we will build all the commits for this project. Once turned on, we will only build branches that have associated pull requests open. Note: For your default branch, we will always build all commits.

• On
• Off

Auto-cancel redundant builds (Does not apply to workflows)

With the exception of your default branch, we will automatically cancel any queued or running builds on a branch when a newer build is triggered on that same branch. This feature will only apply to builds triggered by pushes to GitHub.

• On
• Off

After installing terminus and composer, and creating machine tokens for Git and CircleCI, I am getting the following error with terminus build:project:create :

sh: composer: command not found
[error]  Command `composer create-project --working-dir=/private/var/folders/t7/nws79l7d2njdv93c7l2bn5gr0000gn/T/local-sitegSZqNc pantheon-systems/example-drops-8-composer pantheon-d8-test -n ` failed with exit code 127

I am able to composer create-project with https://github.com/drupal-composer/drupal-project, with no issues, so not sure if this is something on my end or not? Any help would be appreciated.

Hi!

composer -n build-assets returns
[Symfony\Component\Console\Exception\CommandNotFoundException]
Command "build-assets" is not defined.

As a result the build fails.

I was following the example code from https://pantheon.io/docs/guides/build-tools/create-project/ and on the step ( terminus build:project:create d8 my-project-name ) I ran into the error ( Error - Command git -C _path_ commit -m 'Initial commit' failed with exit code 1 ).

From the logging that goes on I can see that it passes:
Creating GitHub project
Call GitHub API
Creating project and resolving dependencies (with suggesting for installing components)
Creates repository
Call GitHub API
Runs git init, followed with success message
Runs git remote add
Creates site 'site' in org ' ' with upstream empty
Creates a new Pantheon site 'site'
Deploys empty to Pantheon site (this step is one of my concerns)
Deploys CMS
Creates a new Pantheon site with UUID 'UUID'
Runs git add (followed my a load of warnings about line endings)
Runs git commit

Then it says:
error: pathspec 'commit'' did not match any file(s) known to git
[error] Command git -C _path_ -m 'Initial commit' failed with exit code 1

I checked to see if git had been initialised in the directory specified in the log and it appears it hasn't. When I entered the specified directory there is a .git directory but git commands do not work within it.

I checked to see if my GitHub has a new repo as the log mentioned it passed that, and it does not appear to to be there either.

The pantheon dashboard also does not show any more sandbox sites.

I should mention I'm doing this on a windows PC running the commands on MinGW64. On thing I did notice on the log is the path is 'C:\Users\me\etc/site-name' I'm not sure if this is the cause of the error or not, but though it worth noting it here.

Any guidance would be greatly appreciated.

Although they are both less than 100 lines, both composer.json and circle.yml have a lot of complexity that we are likely to copy into other repos for WordPress, Drupal 7, and many Drupal distributions like Lightning and commerce. To make the maintenance of a growing number of Composer examples more sustainable, we should reevaluate dependencies and places code can be shared. I will make individual issues for specific topics like

• abstracting dependencies included for tests into a common testing package as we have done with WordPress: https://github.com/pantheon-systems/pantheon-wordpress-upstream-tests
• Removing installer-paths config from composer.json and moving it to a package (since we are already relying an a Pantheon-specific package to provide Quicksilver installer-paths)
• Reducing the need for repeated references to drupal-scaffold.
• Refactoring circle.yml for the coming CircleCI 2.0 (which will allow for common global dependencies used in many Pantheon repos like Terminus, Terminus plugins, and CGR to be pre-installed via Docker file)

Good Morning,

Trying to build a new site on Pantheon but having issues with multiple Terminus Errors. I've troubleshooted and added Php curl and Php xml, but can't seem to find the source of the error below. I'm using a VM with Ubuntu, thanks for the help

c@c-VirtualBox:~$ terminus build:project:create d8 inthmmgt

Enter the password you would like to use to log in to your test site,
or leave empty for a random password::

[notice] Create GitHub project inthmmgt from pantheon-systems/example-drops-8-composer
[notice] Call GitHub API: user
[notice] Creating project and resolving dependencies.
[notice] Running composer create-project --working-dir=/tmp/local-siteMxuWmx pantheon-systems/example-drops-8-composer inthmmgt -n
Installing pantheon-systems/example-drops-8-composer (1.3.9)

• Installing pantheon-systems/example-drops-8-composer (1.3.9): Loading from cache
  Created project in inthmmgt
  Loading composer repositories with package information
  Installing dependencies (including require-dev) from lock file
  Your requirements could not be resolved to an installable set of packages.

Problem 1
- Installation request for alchemy/zippy 0.4.3 -> satisfiable by alchemy/zippy[0.4.3].
- alchemy/zippy 0.4.3 requires ext-mbstring * -> the requested PHP extension mbstring is missing from your system.
Problem 2
- Installation request for drupal/core 8.5.3 -> satisfiable by drupal/core[8.5.3].
- drupal/core 8.5.3 requires ext-gd * -> the requested PHP extension gd is missing from your system.
Problem 3
- Installation request for easyrdf/easyrdf 0.9.1 -> satisfiable by easyrdf/easyrdf[0.9.1].
- easyrdf/easyrdf 0.9.1 requires ext-mbstring * -> the requested PHP extension mbstring is missing from your system.
Problem 4
- Installation request for behat/behat v3.4.3 -> satisfiable by behat/behat[v3.4.3].
- behat/behat v3.4.3 requires ext-mbstring * -> the requested PHP extension mbstring is missing from your system.
Problem 5
- alchemy/zippy 0.4.3 requires ext-mbstring * -> the requested PHP extension mbstring is missing from your system.
- drupal/console 1.8.0 requires alchemy/zippy 0.4.3 -> satisfiable by alchemy/zippy[0.4.3].
- Installation request for drupal/console 1.8.0 -> satisfiable by drupal/console[1.8.0].

To enable extensions, verify that they are enabled in your .ini files:
- /etc/php/7.2/cli/php.ini
- /etc/php/7.2/cli/conf.d/10-opcache.ini
- /etc/php/7.2/cli/conf.d/10-pdo.ini
- /etc/php/7.2/cli/conf.d/15-xml.ini
- /etc/php/7.2/cli/conf.d/20-calendar.ini
- /etc/php/7.2/cli/conf.d/20-ctype.ini
- /etc/php/7.2/cli/conf.d/20-curl.ini
- /etc/php/7.2/cli/conf.d/20-dom.ini
- /etc/php/7.2/cli/conf.d/20-exif.ini
- /etc/php/7.2/cli/conf.d/20-fileinfo.ini
- /etc/php/7.2/cli/conf.d/20-ftp.ini
- /etc/php/7.2/cli/conf.d/20-gettext.ini
- /etc/php/7.2/cli/conf.d/20-iconv.ini
- /etc/php/7.2/cli/conf.d/20-json.ini
- /etc/php/7.2/cli/conf.d/20-phar.ini
- /etc/php/7.2/cli/conf.d/20-posix.ini
- /etc/php/7.2/cli/conf.d/20-readline.ini
- /etc/php/7.2/cli/conf.d/20-shmop.ini
- /etc/php/7.2/cli/conf.d/20-simplexml.ini
- /etc/php/7.2/cli/conf.d/20-sockets.ini
- /etc/php/7.2/cli/conf.d/20-sysvmsg.ini
- /etc/php/7.2/cli/conf.d/20-sysvsem.ini
- /etc/php/7.2/cli/conf.d/20-sysvshm.ini
- /etc/php/7.2/cli/conf.d/20-tokenizer.ini
- /etc/php/7.2/cli/conf.d/20-wddx.ini
- /etc/php/7.2/cli/conf.d/20-xmlreader.ini
- /etc/php/7.2/cli/conf.d/20-xmlwriter.ini
- /etc/php/7.2/cli/conf.d/20-xsl.ini
You can also run php --ini inside terminal to see which files are used by PHP in CLI mode.
[error] Command composer create-project --working-dir=/tmp/local-siteMxuWmx pantheon-systems/example-drops-8-composer inthmmgt -n failed with exit code 2

I am using the Manual Setup instructions. When I execute:
$ composer prepare-for-pantheon

I get an exception:

  [Symfony\Component\Finder\Exception\AccessDeniedException]                                                        
  RecursiveDirectoryIterator::__construct(/Users/lisastreeter/Desktop/Sync/worthington/vendor/dflydev/dot-access-c  
  onfiguration/.git): failed to open dir: No such file or directory  

and:

 [UnexpectedValueException]                                                                                        
  RecursiveDirectoryIterator::__construct(/Users/lisastreeter/Desktop/Sync/worthington/vendor/dflydev/dot-access-c  
  onfiguration/.git): failed to open dir: No such file or directory    

Before I run the prepare-for-pantheon command, the .git directory does exist in that location. After I run the command, the .git directory is no longer there. So it seems like it's trying to remove the same directory twice.

The pantheon.settings.php has the configuration set to:

CONFIG_SYNC_DIRECTORY => 'sites/default/config',

Can we update it to:

CONFIG_SYNC_DIRECTORY => '../config',

(hoping it's not a dupe issue; I promise I searched first!)

Y'all's composer.json file is indented with 2-space indents, but indent size for composer.json/lock files is supposed to be 4.

And yet, y'all's composer.LOCK file is 4-space-indented.

I only noticed b/c I was checking/making sure of some stuff between my composer.json in a project that was originally based on example-drops-8-composer, and before I knew it, my indents were different, and then I couldn't figure out why....... and here I am.

My initial guess is that it's b/c y'all don't have the .editorconfig that comes with Drupal core, or the one in drupal-scaffold, in this repo.

Anyway, here's my source material:
https://github.com/drupal-composer/drupal-scaffold/blob/master/.editorconfig
(and like I said, it's in the one that lives in web/ after you install Drupal)

Currently
https://github.com/pantheon-systems/example-drops-8-composer/blob/master/.circleci/scripts/pantheon/09-cleanup-fixtures

Does nothing :(

Not sure if this belongs here but the .circleci scripts are here so it must be close.

I would like the scripts and documentation to support a "destroy after merge or close" workflow, so I don't have to manually destroy PR multidev environments. I think #160 would need to be resolved first so the multidev environment name creation is consistent enough to target the destroy.

Composer update fails and returns this message:

[Composer\Downloader\TransportException] The "https://raw.githubusercontent.com/pantheon-systems/drops-8/8.3.6/.gitattributes" file could not be downloaded (HTTP/1.1 404 Not Found)

It looks like the proper path would be: https://raw.githubusercontent.com/pantheon-systems/drops-8/update-8.3.6/.gitattributes

I was curious why my builds weren't running a config-import.
Turns out I had forgotten to update the init-site-under-test task after i changed my config directory.

Would it be possible to pull this from settings or drush or similar, rather than hard-coding the path here?

The example-drops-8-composer project uses the Behat Drupal Driver to run tests, so the multidev environment is not altered by the test procedure. This is not 100% reliable, though; it is possible that users may add their own tests that alter the multidev state.

The example-wordpress-composer repository explicitly backs up the environment before the test, and then restores it again. This has the advantage of keeping the multidev in a state where it could be used for other purposes, e.g. for an agency to review work-in-progress with a client.

Usually, instead of backup-alter-restore, a more stable design paradigm is copy-alter (the copy)-destroy.

Disadvantages of backup / restore over copy / delete:

• Complexity of implementation
  • Restore might not happen if the test fails, unless there is a when on_fail step to catch this.
  • If there is an on_fail step, it must be skipped if the step failed before the backup was made
• Potentially dangerous
  • Work might be lost if an agency makes a change after the backup, but before the restore. (Tests take minutes to run, and users are not necessarily aware of what stage the tests are in when they are using the multidev.)

The use-case for having a usable pr multidev might be better served by simply using a ci-BUILD_NUMBER multidev to run all tests, and make a pr-PULL_REQUEST_ID multidev only for agency use -- never for test running. The ci-* multidevs are cleaned up later (we could do this in a separate Circle CI 2.0 build step, in parallel with the other steps), so we'd have to compare the cost of multidev creation against the comparable cost of one backup + one restore. The time trade-offs may differ for small sites vs. large sites. It is likely that multidev creation is slower than backup + restore, especially for smaller sites. We need to weigh the performance cost against the disadvantages of backup / restore.

In the composer.json file of this project, it has this name
"name": "pantheon-systems/drops-8-composer",

Should it be "name": "pantheon-systems/example-drops-8-composer", instead?

Those who are using the #composer-workflow and wish to apply the Drupal security update ASAP after its release, please follow the procedure below:

1. Update your project to include the change from 96b334c. Do this in advance, and test to ensure that it works.
2. When the Drupal security update is released and tagged on drupal/core, update your project as usual.

The above-referenced project, pantheon-systems/drops-8-scaffolding, is simply a clone of pantheon-systems/drops-8 with the /core, /composer.lock and /vendor directories removed. This project will be tagged as soon as the drupal/core project update is released. The drops-8 project will be tagged as soon as the update is released and tested on Pantheon. By using drops-8-scaffolding, you may do your own testing in parallel with Pantheon's testing for a faster release. For a patch release, this is very likely to work without issue.

If you are not using the composer workflow, or if you wish to wait for Pantheon to test the release first, simply wait for the drops-8 project to be tagged, and then update as usual. We will strive to make this release available within an hour of the upstream release of Drupal.

WILL MY SITE BE AT RISK IF I WAIT FOR PANTHEON TO TEST THE RELEASE?

When Drupalgeddon was disclosed in late 2014, exploits attacking the vulnerability were observed within seven hours of the patch release that fixed it. Pantheon will have engineers monitoring our systems, and will make every effort to block hostile requests before they reach customer sites. The only way to be 100% safe, though, is to upgrade Drupal to the latest version as soon as possible.

Expected behavior:
Site should be on Drupal 8.6.0

Actual behavior:
Site is still on Drupal 8.5.5

https://github.com/qlstudent/utah
http://dev-utah.pantheonsite.io/

Would you consider adding a way for forks to include an additional composer.json file for customization? Maybe composer-local.json and merging it with the composer merge plugin. If so, I'll work on it and provide a pull request. If not, is the best practice to merge your changes into our custom composer.json every time it updates?

"require" : {
"wikimedia/composer-merge-plugin": "dev-master"
},
"extra": {
"merge-plugin": {
"include": [ "composer-local.json" ]
}
}

See #107 (comment) and surrounding discussion.

Have been running into an issue where the multidev cleanup stage of the stock build process is always failing.

The following terminus command fails if enabled in the '01-prepare' script. When disabled the rest of the build process completes as expected.

terminus -n build:env:delete:ci "$TERMINUS_SITE" --keep=2 --yes

The relevant Circle CI output that I see when that step is enabled:

[notice] Rsync ci-18.<pantheon server/site ID>@appserver.ci-18.<pantheon server/site ID>.drush.in:code/build-metadata.json => /tmp/build-metadata.json
[notice] Call GitHub API: repos/[email protected]:<my private repo.git>/pulls?state=open
[error] GitHub error: Not Found. Http status code: 404

• Everything under .circleci/scripts/pantheon is a copy/paste of this repo.
• The repo is a private GitHub repo
• There is an open PR and Circle CI is toggled to only build PR's
• The GITHUB_TOKEN has repo scope perms and is from a user with write access to the repo.
• The rest of the process completes as expected outside of this step.

This also affects the PR multidev cleanup stage in 04-merge-master

terminus -n build:env:delete:pr "$TERMINUS_SITE" --yes

I'm confused about the two webflo/* "pinning" packages.

I read through [#116] (that's where I got the "pinning" term). Even just in the first response, I was already confused -- I get what webflo/drupal-core-strict does, but then the suggestion uses webflo/drupal-core-require-dev.

Context: I ended up in this confused place because I hadn't looked at drupal-composer/drupal-project in a while, and I saw that they replaced the require-dev lines with webflo/drupal-core-require-dev. My own composer-managed Drupal 8 site was originally based on pantheon-systems/example-drops-8-composer, so my next step was to look at the composer.json file in this project -- this project requires webflo/drupal-core-strict but not webflo/drupal-core-require-dev -- so I was just going to ask y'all if you aren't using drupal-core-require-dev for a specific reason, or if it simply hasn't happened, no specific reason, and then I came upon issue #116, and now I'm here.

I thiiiiink actually maybe, contrary to how I interpret that issue thread [#116] (and maybe I misunderstood), these two pinning projects don't conflict, they simply do different things, right? Or?

I had been (sporadically) following the dependencies specified in the example-drops-8-composer composer.json, because all our sites are on Pantheon, but now I'm wondering...

1. Do you still recommend using drupal-core-strict? I ask because it's a divergence from drupal-composer/drupal-project, so I just want to understand.
2. Are you not using drupal-core-require-dev because of a conflict or some other reason, or simply because it hasn't gotten in? (again, I just want to understand)

Thank you!

Subtask of #61

Making a custom Docker image to test the Terminus Build Tools plugin was actually really easy. See:

• https://github.com/pantheon-systems/docker-php-ci
• https://quay.io/repository/pantheon-public/php-ci
• pantheon-systems/terminus-build-tools-plugin#101

This same technique could be used to reduce the boilerplate currently in the circle.yml in this project. When we convert to Circle 2.0, we can make a custom docker image similar to the one above (except that we will add the Terminus Build Tools plugin & c., and will not add Ruby or the Circle CI tool). Furthermore, we can also put sections of the scripts currently in circle.yml directly into our image.

• Our .circle/config.yml will run scripts at well-known paths in the docker image
• A comment will link to the script in question in the source github repo
• If we update the testig steps in the docker image, all derived projects will get the update
• Folks who want to freeze or customize the test steps can copy them into their .circle dir
• Custom build steps are still done via composer build-assets

Pantheon's composer.json file is very similar to the one used by the drupal-composer project.

Support for the drupal-library installer-paths is missing.

"web/libraries/{$name}": ["type:drupal-library"],

Someone noticed this issue with the Webform module's composer integration

Issue #3016309: Use composer merge plugin when document root is /web

The Icon rule is blocking this directory:
/core/lib/Drupal/Core/Layout/Icon/

See #107 for background.

• Run or skip tests on non-pull-request builds: pantheon-systems/example-wordpress-composer#40
• Backup site before tests, restore after tests #113
• Run terminus wp or terminus drush prior to starting behat tests
• Delete and re-create test admin user prior to starting behat tests

@greg-1-anderson, add-commit-comment, seems like exactly the kind of file we just discussed as belonging better in the container rather than the project repo. Do you agree?

After manual install got:

Warning: require(/srv/bindings/3ff8997034df42a7a7b6fb7303d8fe9c/code/web/../vendor/autoload.php): failed to open stream: No such file or directory in /srv/bindings/3ff8997034df42a7a7b6fb7303d8fe9c/code/web/autoload.php on line 17 Fatal error: require(): Failed opening required '/srv/bindings/3ff8997034df42a7a7b6fb7303d8fe9c/code/web/../vendor/autoload.php' (include_path='.:/usr/share/pear:/usr/share/php') in /srv/bindings/3ff8997034df42a7a7b6fb7303d8fe9c/code/web/autoload.php on line 17

Internal bug report from Lauren came in through support chat:

Based on the instructions here https://github.com/pantheon-systems/example-drops-8-composer both the upstream and manual installs are failing.

We cannot see the exact issue on the upstream installs, but on the manual installs, we are seeing the following error:
[Symfony\Component\Console\Exception\CommandNotFoundException]
Command "prepare-for-pantheon" is not defined.

Joseph Bonilla looked and saw that https://github.com/pantheon-systems/example-drops-8-composer/blob/master/composer.json#L46-L50 was not in his local copy.

The "Icon" directory exists in Drupal core.

screen shot : http://z.alphex.io/2018-07-11_14-31-34--d855h.jpg

I'm unsure what the goal of this is, but, maybe just change it to /Icon ?

Hiya! Normal (for me) caveats -- I could be mistaken, I may have misunderstood, etc etc --

Looking at scripts/composer/ScriptHandler.php...

I think the { characters are supposed to be on the same line as class/function/etc declarations -- just based on the examples on the d.o OOP coding standards doc (...and based on the version of this file that's in drupal-composer/drupal-project -- but the doc on d.o is a more compelling reason in my book).

So, for ScriptHandler.php, the change would look like this:

-class ScriptHandler
-{
+class ScriptHandler {
 
-  protected static function getDrupalRoot($project_root)
-  {
+  protected static function getDrupalRoot($project_root) {

(etc.)

ANYWAY, not urgent, just, lmk what y'all think -- if you agree, I'm happy to submit a PR with the new-line changes. Thanks!

I'm curious why the composer.json requires the Simple Block module. Is this necessary for sites built using the Pantheon Build Tools, or is it just included for convenience?

I built a new site, and the following files are missing from the Github repository:

default.services.pantheon.preproduction.yml
default.services.yml
default.settings.php
settings.pantheon.php

services.yml is missing both from the Pantheon deployment and from the repository. The only file in both places is settings.php.

The Pantheon dashboard warns about the missing services file (neat!), but the other files are pretty useful for developers, and the settings.pantheon.php file is documented as being required on locals too.

Updating to Drupal 8.3.1 gives the following composer error:

[Composer\Downloader\TransportException]                                                                                                     
  The "https://raw.githubusercontent.com/pantheon-systems/drops-8/8.3.1/.gitattributes" file could not be downloaded (HTTP/1.1 404 Not Found)

Just hard coded it to 8.3.0 in order for it to work but it would be nice to get it fixed.

Here is a break-out issue from #61 (comment)

The file add-commit-comment does not need to be specific to this repo. It could be moved to inside a Docker container after #107 lands or to a shared Composer project.

Mostly rubber ducking this but feedback welcomed!

This project is not forked or modified in any way, followed instructions here https://pantheon.io/docs/guides/build-tools/

Example PR here, multidev created is ci-9, not pr-2
ElijahLynn/pantheon-d8-composer-project-elijah#2

I do see that it should be named after PR here https://github.com/pantheon-systems/docker-build-tools-ci/blob/1.x/scripts/set-environment#L24.

Investigating...

related to #116