omega8cc
boa 5 dev: Command "cd" is not defined in verify platform task
I've been testing out boa for D9 sites that require PHP version of 8.0/1 for composer builds. Haven't been able to get it to work reliably in v4. If I switch CLI to 8.1 but use 7.4 for the rest I have issues with migration, clone, etc. Thought I would try latest dev.
Think I found a bug. On platform build it fails on Command "cd" is not defined in verify platform task
Executing: `cd '/data/disk/o1/static/efc-test-boa-5' && git checkout 'main'` [2.68 sec, 10.32 MB] [notice]
Already on 'main' [notice]
[2.78 sec, 10.33 MB]
Finished running: `cd '/data/disk/o1/static/efc-test-boa-5' && git checkout 'main'` [2.78 sec, 10.32 MB] [success]
Executing: `cd '/data/disk/o1/static/efc-test-boa-5' && composer create-project --no-dev --no-interaction --no-progress` [2.78 sec, 10.32 MB] [notice]
[notice]
[3.1 sec, 10.33 MB]
[notice]
[3.11 sec, 10.33 MB]
Command "cd" is not defined. [notice]
[3.11 sec, 10.33 MB]
[notice]
[3.11 sec, 10.33 MB]
[notice]
[3.11 sec, 10.33 MB]
An error occured when running command! (returned 1) [3.12 sec, 26.14 MB] [error]
Returned from hook drush_platform_composer_git_provision_verify_validate [3.11 sec, 10.32 MB] [debug]
Command dispatch complete [3.12 sec, 10.26 MB] [notice]
Returned from hook drush_hosting_task [3.13 sec, 26.17 MB] [debug]
Invoking <em class="placeholder">hosting_verify_task_rollback</em> hooks. [3.13 sec, 26.17 MB] [notice]
Changes made in drush_hosting_task have been rolled back. [3.13 sec, 26.17 MB] [debug]
Command dispatch complete [3.13 sec, 26.01 MB] [notice]
Timer Cum (sec) Count Avg (msec)
page 2.964 1 2964.01
Updated task status to "Failed" [3.13 sec, 26.08 MB] [info]
System info
Skynet Agent v.BOA-5.0.0-dev on Debian/bullseye welcomes you aboard
cat .barracuda.cnf
###
### Configuration created on 230902-052120
###
_LOCAL_NETWORK_HN=""
_LOCAL_NETWORK_IP=""
_MY_FRONT="master.server2.mydomain.com"
_MY_HOSTN="server2.mydomain.com"
_MY_OWNIP="173.255.213.70"
_SMTP_RELAY_HOST=""
_SMTP_RELAY_TEST=YES
_THIS_DB_HOST=localhost
###
_AUTOPILOT=YES
_DEBUG_MODE=NO
_MY_EMAIL="[email protected]"
_XTRAS_LIST="ADM CSF FTP CSS DCS"
###
_MODULES_FIX=YES
_MODULES_SKIP=""
_PERMISSIONS_FIX=YES
###
_CPU_CRIT_RATIO=9
_CPU_MAX_RATIO=6
_CPU_SPIDER_RATIO=3
###
_DB_BINARY_LOG=NO
_DB_SERIES=5.7
_DB_SERVER=Percona
_USE_MYSQLTUNER=YES
###
_DNS_SETUP_TEST=YES
_EXTRA_PACKAGES=
_FORCE_GIT_MIRROR=""
_LOCAL_DEVUAN_MIRROR=deb.devuan.org
_LOCAL_DEBIAN_MIRROR=deb.debian.org
_LOCAL_UBUNTU_MIRROR=archive.ubuntu.com
_NEWRELIC_KEY=
_SCOUT_KEY=
###
_MAGICK_FROM_SOURCES=NO
###
_NGINX_DOS_LIMIT=399
_NGINX_EXTRA_CONF=""
_NGINX_FORWARD_SECRECY=YES
_NGINX_HEADERS=NO
_NGINX_LDAP=NO
_NGINX_NAXSI=NO
_NGINX_SPDY=YES
_NGINX_WORKERS=AUTO
###
_PHP_CLI_VERSION=8.1
_PHP_EXTRA_CONF=""
_PHP_FPM_DENY=""
_PHP_FPM_VERSION=8.1
_PHP_FPM_WORKERS=AUTO
_PHP_IONCUBE=NO
_PHP_GEOS=NO
_PHP_MONGODB=NO
_PHP_MULTI_INSTALL="7.4 8.1 8.2"
_PHP_SINGLE_INSTALL=
###
_REDIS_LISTEN_MODE=SOCKET
_REDIS_MAJOR_RELEASE=7
_RESERVED_RAM=0
_SPEED_VALID_MAX=3600
_SSH_ARMOUR=NO
_SSH_FROM_SOURCES=YES
_SSH_PORT=22
_STRICT_BIN_PERMISSIONS=YES
_STRONG_PASSWORDS=NO
###
_CUSTOM_CONFIG_CSF=NO
_CUSTOM_CONFIG_LSHELL=NO
_CUSTOM_CONFIG_REDIS=NO
_CUSTOM_CONFIG_SQL=NO
###
_AEGIR_UPGRADE_ONLY=NO
_SYSTEM_UPGRADE_ONLY=YES
###
cat .o1.octopus.cnf
###
### Configuration created on 230902-061546 with
### Octopus version BOA-4.2.0-stable
###
_USER="o1"
_MY_EMAIL="[email protected]"
_PLATFORMS_LIST="none"
_AUTOPILOT=NO
_HM_ONLY=NO
_DEBUG_MODE=NO
_MY_OWNIP=
_FORCE_GIT_MIRROR=""
_THIS_DB_HOST=localhost
_THIS_DB_PORT=3306
_DNS_SETUP_TEST=YES
_HOT_SAUCE=NO
_USE_CURRENT=YES
_DEL_OLD_EMPTY_PLATFORMS=0
_DEL_OLD_BACKUPS=0
_DEL_OLD_TMP=0
_LOCAL_NETWORK_IP=
_PHP_FPM_VERSION=8.1
_PHP_CLI_VERSION=8.1
_PHP_FPM_WORKERS=AUTO
_PHP_FPM_TIMEOUT=AUTO
_PHP_FPM_DENY=""
_STRONG_PASSWORDS=NO
_SQL_CONVERT=NO
_RESERVED_RAM=0
###
_DOMAIN="o1.server2.mydomain.com"
_CLIENT_EMAIL="[email protected]"
_CLIENT_OPTION="POWER"
_CLIENT_SUBSCR="M"
_CLIENT_CORES="1"
###
Can you still reproduce this with BOA-5.1.0? We haven't seen this error before.
I was getting this same error when trying to create a platform prior to running upgrade.
After completing upgrade, using standard not auto, I'm getting this same error. Upgraded to 5.1.0 and when trying to create a new platform, it fails and get the error:
Command cd is not defined
An error occured when running command! (returned 1)
I used the standard upgrade because previous attempt at auto upgrade didn't complete. So, I ran the standard upgrade and did not have the OS upgrade to try and get BOA to the new version 5. OS is still at Debian Stretch. Maybe that is the problem?
Ok, this is the same thing that we were getting earlier in the year when an automated change happened
https://github.com/omega8cc/boa/issues/1707
This same thing is happening on my server that is running 4.2.0 stable on Devuan/Beowulf, so it's not just a fact of the other being on Debian Stretch.
But, the fact that it was happening after the upgrade to 5.1.0 was disheartening. Will be attempting upgrade on server running Beofulf and keeping fingers crossed things work correctly.
@dserrato You haven’t responded to our request for testing in May so we have merged in the new updates to stable a few months ago, it’s not something new now. If everything worked for you until BOA 5.x release then maybe there’s another regression, so we welcome further testing and submitting bugs with steps to reproduce because we don’t use Composer builds in Aegir directly.
Sent with GitHawk
Yea, I've been going back over that documentation in that issue and recall that you were going to reintroduce it back in. It was interesting that it's been working flawlessly until this last week when it popped up. Then, in doing the upgrade last night, everything was working great with 5.1.0, but upon trying to create a platform, it ran into the same issue. So, since you don't use composer in your testing, what do you use/recommend? Do you only create platforms from a git repository of complete drupal code and modules/themes rather than a composer file?
We build platforms on command line using external scripting like we did with Drush before, because we have disabled running Composer in our Aegir fork by default after experiencing tons of failed builds or confusing failed verify tasks which need manual cleanup, so we simply don’t have the opportunity nor need to test the builds the way you use them. That’s why it could be helpful if you could share some Composer file we could test too to stay on the same page. We don’t want to enforce our workflow but to fix the problem for your workflow.
Sent with GitHawk
Thank you very much for the feedback and I'm hoping to help in any way I can. I apologize for my inability to get to the previous testing that you had requested so long ago. Our team is so small (but mighty) and we have our hands so full. But, BOA has been the key for us to do the tremendous amount of work that we do! ;-)
Here is an example of a composer file that we would use. I just removed our custom theme from the listing.
https://bitbucket.org/dserrato/site-composer-build/src/main/
Our process that works so well is this:
- Build Drupal locally using DDEV with a composer build
- Add all modules using composer so that we get all required modules & libraries needed for all modules
- Add our custom themes and/or modules to the composer file since they are git repos as well
- Complete the development of the site and commit the composer file with locked versions of modules.
- We lock all the modules and Drupal to exact versions so that we can control the migration of sites exactly.
- If a new version of Drupal and modules come out for the sites on that platform, we can test locally and then adjust the composer file to the exact versions that we will update to.
- Adjust the composer file, commit the changes, add a new tag (1.0.1 to 1.02 for the composer git repo) and push changes to Bitbucket
- Create a new platform using the "Deploy a Composer project from a Git repository" choice and use the url and the new tag and use "web" as the Docroot
- Create a clone of the site
- Test the migration of that site to the new platform
- If all is good, migrate live site to new platform
- Celebrate!!!
In the case of some platforms, we are hosting several sites. When a department in our organization needs a new site, we spin up a site on the needed platform and build a beginning site for them to get started. The ability to migrate all sites on a platform to the upgraded platform is a huge help as well.
Since I've been using BOA since the D7 days, I began by using Makefiles as a recipe for a platform. This current method is the same idea of a recipe, but using Git to control the versioning of the composer file to build new platforms.
It's a wonderful, efficient and reliable way to control platforms.
Hope that my bit of information can help to enhance the workflow and assist in making it possible to use this method that is so incredibly powerful.
I am having the same issue. I am creating a new platform using Deploy a Composer project from a Git repository, setting Docroot to web and the URL of my Git repo.
Skynet Agent v.BOA-5.1.0-head on Devuan/chimaera
PHP: 8.1
cat .barracuda.cnf
###
### Configuration created on 180916-1337
###
_LOCAL_NETWORK_HN=""
_LOCAL_NETWORK_IP=""
_MY_FRONT="master.server.navideck.com"
_MY_HOSTN="server.navideck.com"
_MY_OWNIP="95.216.173.8"
_SMTP_RELAY_HOST=""
_SMTP_RELAY_TEST=YES
_THIS_DB_HOST=localhost
###
_AUTOPILOT=YES
_DEBUG_MODE=NO
_MY_EMAIL="[email protected]"
_XTRAS_LIST="ADM CSF FTP"
###
_MODULES_FIX=YES
_MODULES_SKIP=""
_PERMISSIONS_FIX=YES
###
_CPU_CRIT_RATIO=9
_CPU_MAX_RATIO=6
_CPU_SPIDER_RATIO=3
###
_DB_BINARY_LOG=NO
_DB_SERIES=5.7
_DB_SERVER=Percona
_USE_MYSQLTUNER=YES
###
_DNS_SETUP_TEST=YES
_EXTRA_PACKAGES=
_FORCE_GIT_MIRROR=""
_LOCAL_DEBIAN_MIRROR=deb.debian.org
_LOCAL_UBUNTU_MIRROR=archive.ubuntu.com
_NEWRELIC_KEY=
_SCOUT_KEY=
###
_MAGICK_FROM_SOURCES=NO
###
_NGINX_DOS_LIMIT=399
_NGINX_EXTRA_CONF=""
_NGINX_FORWARD_SECRECY=YES
_NGINX_HEADERS=NO
_NGINX_LDAP=NO
_NGINX_NAXSI=NO
_NGINX_SPDY=YES
_NGINX_WORKERS=AUTO
###
_PHP_CLI_VERSION=8.1
_PHP_EXTRA_CONF=""
_PHP_FPM_DENY=""
_PHP_FPM_VERSION=8.1
_PHP_FPM_WORKERS=AUTO
_PHP_IONCUBE=NO
_PHP_GEOS=NO
_PHP_MONGODB=NO
_PHP_SINGLE_INSTALL=
###
_REDIS_LISTEN_MODE=SOCKET
_RESERVED_RAM=0
_SPEED_VALID_MAX=3600
_SSH_ARMOUR=NO
_SSH_FROM_SOURCES=YES
_SSH_PORT=22
_STRICT_BIN_PERMISSIONS=YES
_STRONG_PASSWORDS=NO
###
_CUSTOM_CONFIG_CSF=NO
_CUSTOM_CONFIG_LSHELL=NO
_CUSTOM_CONFIG_REDIS=NO
_CUSTOM_CONFIG_SQL=NO
###
_AEGIR_UPGRADE_ONLY=NO
_SYSTEM_UPGRADE_ONLY=YES
###
_REDIS_MAJOR_RELEASE=7
_PHP_MULTI_INSTALL="8.1"
cat .o1.octopus.cnf
###
### Configuration created on 180916-1404 with
### Octopus version BOA-3.2.2
###
_USER="o1"
_MY_EMAIL="[email protected]"
_PLATFORMS_LIST="ALL"
_AUTOPILOT=NO
_HM_ONLY=NO
_DEBUG_MODE=NO
_MY_OWNIP=
_FORCE_GIT_MIRROR=""
_THIS_DB_HOST=localhost
_THIS_DB_PORT=3306
_DNS_SETUP_TEST=YES
_HOT_SAUCE=NO
_USE_CURRENT=YES
_DEL_OLD_EMPTY_PLATFORMS=0
_DEL_OLD_BACKUPS=0
_DEL_OLD_TMP=0
_LOCAL_NETWORK_IP=
_PHP_FPM_VERSION=8.1
_PHP_CLI_VERSION=8.1
_PHP_FPM_WORKERS=AUTO
_PHP_FPM_TIMEOUT=AUTO
_PHP_FPM_DENY=""
_STRONG_PASSWORDS=NO
_SQL_CONVERT=NO
_RESERVED_RAM=0
###
_DOMAIN="o1.server.navideck.com"
_CLIENT_EMAIL="[email protected]"
_CLIENT_OPTION="SSD"
_CLIENT_SUBSCR="Y"
_CLIENT_CORES="8"
###
Hello, all. Has anyone been able to figure out what's happening with this one? I, too, have been running into this when deploying a composer project from a git repository.
Interestingly, if I copy the very same command that it attempts to execute and run it myself from the command line as the o1 user, it works perfectly--the project is created, the platform verifies successfully, and I can proceed with building sites on the new platform, even from the UI. Even more interesting is that this command appears to come from the buildCreateProjectCommand function which immediately follows the buildCheckoutVersionCommand function, and that one also begins with a cd, and it works just fine from the UI. You can actually see that it finishes successfully in the screenshot above from @fotiDim. It's really odd that the very next one throws a command "cd" is not defined notice.
If it helps at all, my task log looks pretty much identical to the screenshot above, with two blank lines before and two blank lines after command "cd" is not defined and then the error.
@chadamas Can you please elaborate on the commands you run? Do you run them after the platform creation fails (and folder is created) or in a clean state? In my case o1 has disabled shell but o1.ftp does not.
EDIT - Found some steps that work:
- Create platform though the UI and let it fail with the
cderror - SSH to the server as root and then
su o1.ftp - Run
cd /data/disk/o1/static/MY_NEW_PLATFORM - Run
composer create-project --no-dev Verify + Lock Drushthe platform through the UI
@omega8cc thanks for the update. Can you elaborate on what you mean by "stable release"? I thought barracuda up-lite system would keep me on the stable branch.
We no longer call any branch stable, but actually any release means stable, now for both lite and pro. It has been released yesterday to bring the old head up to speed so we can move to review outstanding issues and hopefully work on a hotfix for the feature we don’t use ourselves but should be fixed anyway.
Sent with GitHawk
To reiterate: when new BOA release is published you must run full barracuda and octopus upgrades, not just barracuda system which is designed to run mainly system packages updates and hotfixes between releases. It’s explained in the documentation.
Sent with GitHawk
To reiterate: when new BOA release is published you must run full barracuda and octopus upgrades, not just barracuda system which is designed to run mainly system packages updates and hotfixes between releases. It’s explained in the documentation.
Sent with GitHawk
Still happening for me after running all the proper barracuda and octopus upgrades.
I managed to "work around" this obscure issue by applying this patch to the platform_composer_git module, which is a submodule of hosting_deploy. /data/disk/o1/aegir/distro/00X/profiles/hostmaster/modules/aegir/hosting_deploy
@GValFr35 This looks like clever solution! Please feel free to submit the patch at https://github.com/omega8cc/hosting_deploy
Sent with GitHawk