The command "extension:activate" does not exist.

[halbkreativ]

Actual Behavior

On 28. April '23 the deployment runs as expected. Today it fails on

TYPO3\Surf\Task\TYPO3\CMS\SetUpExtensionsTask

with message

xxx.your-server.de (TYPO3 CMS) TYPO3\Surf\Task\TYPO3\CMS\SetUpExtensionsTask
    > 
    > [ Symfony\Component\Console\Exception\CommandNotFoundException ]     The command "extension:activate" does not exist.
Got exception "Command returned non-zero return code: 1" rolling back.

Only difference is the TYPO3 version 11.5.26 and 11.5.27.

When installing surf 3.4 as dependency in project composer.json and start deployment inside ddev container it works as expected.

Steps to Reproduce the Problem

1. surf deploy typo3 via gitlab-ci.yaml in current Gitlab CE (self-hosted)

Specifications

• Surf Version: Latest 3.3.x on 28. April, 3.4 now
• Application: TYPO3 11
• PHP Version: 7.4 and 8.1
• Platform:
• Environment (CI):
• Deployment configuration:

Gitlab CI

stages:
  - Build

surf:live:
  stage: Build
  when: manual
  image: t3easy/surf:3-php7.4-composer2-node16
  before_script:
    - eval $(ssh-agent -s)
    - echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add -
    - mkdir -p ~/.ssh
    - chmod 700 ~/.ssh
    - ssh-keyscan -t rsa gitlab.xxx.io >> ~/.ssh/known_hosts
    - ssh-keyscan -t rsa -p 222 xxx.your-server.de >> ~/.ssh/known_hosts
    - chmod 644 ~/.ssh/known_hosts
    - composer config gitlab-token.$CI_SERVER_HOST gitlab-ci-token $CI_JOB_TOKEN
  script:
    - surf deploy typo3

Surf Config:

<?php
/** @var \TYPO3\Surf\Domain\Model\Deployment $deployment */

$node = new \TYPO3\Surf\Domain\Model\Node('xxx.your-server.de');
$node
    ->setHostname($node->getName())
    ->setOption('username', 'xxx')
    ->setOption('port', '222')
    ->setOption('phpBinaryPathAndFilename', '/usr/bin/php');

$application = new \TYPO3\Surf\Application\TYPO3\CMS();
$application
    ->setDeploymentPath('/usr/home/xxx/public_html')
    ->setOption('baseUrl', 'https://xxx.dev.xxx.at/')
    ->setOption('webDirectory', 'htdocs')
    ->setOption('symlinkDataFolders', ['fileadmin'])
    ->setOption('repositoryUrl', getenv('CI_REPOSITORY_URL') !== false ? getenv('CI_REPOSITORY_URL') : 'file://' . dirname(__DIR__))
    ->setOption('branch', getenv('CI_COMMIT_REF_NAME') !== false ? getenv('CI_COMMIT_REF_NAME') : 'main')
    ->setOption('keepReleases', 3)
    ->setOption('composerCommandPath', 'composer')
    ->setOption('rsyncExcludes', [
        '.git*',
        '.ddev',
        '.surf',
        'node_modules',
        '.editorconfig',
        $application->getOption('webDirectory') . '/fileadmin',
    ])
    ->addNode($node);

$deployment
    ->addApplication($application)
    ->onInitialize(
        function () use ($deployment, $application) {
            $deployment->getWorkflow()
                ->defineTask('CopyEnvFileTask', \TYPO3\Surf\Task\ShellTask::class, [
                    'command' => [
                        'cp {sharedPath}/.env {releasePath}/.env',
                        'cd {releasePath}',
                    ]
                ])
                ->afterStage('transfer', 'CopyEnvFileTask', $application)
                ->addTask(\TYPO3\Surf\Task\TYPO3\CMS\CompareDatabaseTask::class, 'migrate', $application)
                ->defineTask('FixFolderStructureTask', \TYPO3\Surf\Task\TYPO3\CMS\RunCommandTask::class, [
                    'command' => 'install:fixfolderstructure'
                ])
                ->addTask('FixFolderStructureTask', 'migrate', $application)
                ->defineTask('LanguageUpdateTask', \TYPO3\Surf\Task\TYPO3\CMS\RunCommandTask::class, [
                    'command' => 'language:update'
                ])
                ->addTask('LanguageUpdateTask', 'migrate', $application)
                ->addTask(\TYPO3\Surf\Task\TYPO3\CMS\WarmupCacheTask::class, 'migrate', $application)
                ->beforeStage('transfer', \TYPO3\Surf\Task\Php\WebOpcacheResetCreateScriptTask::class, $application)
                ->afterStage('switch', \TYPO3\Surf\Task\Php\WebOpcacheResetExecuteTask::class, $application);
        }
    );

[t3easy]

Seams like the version check fails in some cases...

Can you set the version via scriptFileVersion

https://github.com/TYPO3/Surf/blob/master/src/Task/TYPO3/CMS/SetUpExtensionsTask.php#L54

[t3easy]

The new version check @sabbelasichon implemented in ef548c4 only works if surf is part of your project, not if it's at phar or global / separate package.

[halbkreativ]

Yes, with this setting $application->setOption('scriptFileVersion', '7.0.0') it seems to work!

[t3easy]

Thanks for your help @halbkreativ!
Then it seems to be a regression/ breaking change if Surf isn't installed and run from within the composer project as it can only check the version of packages this way if the check is implemented like this.

[halbkreativ]

I've installed ist now first as require-dev and than as "normal" require, but it fails on the same line when deploying with your docker image.

[t3easy]

I've installed ist now first as require-dev and than as "normal" require, but it fails on the same line when deploying with your docker image.

Do you run just surf or ./vendor/bin/surf? As /app/vendor/bin is not in the path right now https://github.com/t3easy/docker-composer/blob/master/Dockerfile#L50 you'll run the global installed surf, not the one from your project. But good point, I'll add /app/vendor/bin to PATH with a higher priority than the globale package folder /tmp/vendor/bin.

[t3easy]

@sabbelasichon the issue with the failing version check if surf is not a package of the TYPO3 project is still present and a regression. I'll reopen the issue.

[instruccionesaldorso]

I can confirm the same problem happened to me in TYPO3 11.5.27 through last deployments and this temporary fix #762 (comment) solved the problem for now.

[fe-hicking]

We're affected by this issue, too.

Our problem is, we try to use a SURF configuration workflow/recipe that is compatible to both TYPO3v11 and TYPO3v12 currently (which Surf tries to support, so thanks for that).

We actually decouple the composer.json requiring Surf from our main TYPO3 project composer.json. This is so that we can deploy different projects, but also so that Surf's composer requirements do not interfer with TYPO3's requirement and those of other extensions. This has worked quite well in the past.

I understand the need that Surf needs to know which typo3console version (or even which TYPO3 version) is installed, but the route through composer.json sadly isn't viable.

Would it be an option to make surf actually inspect the composer.json that is used to setup the workspace for, instead of "it's own" composer.json/lock? I understand executing the typo3(cms) binary on the remote host just to get its version number is not very clean.

[kaystrobach]

Have you tried using surf as a phar?

[fe-hicking]

I read the problem so that when using a PHAR, the same version-detection problem would exist: "only works if surf is part of your project, not if it's at phar or global / separate package."

Having said that - I prefer a distinct "surf project" composer.json over a static phar, just because I have more control over dependencies and can inject other internal dependencies that we use on deployment...

But I don't want to "hijack" this issue for this - I'd be interested in how the process of Surf trying to figure out the TYPO3 console version can be decoupled from being composed into the same project.

[t3easy]

I started with the development of that feature. t3easy@9f0ebf8

The idea is to run composer show as a task after install, and add the information to a property of the application. That would work as a phar, global/separate project and as dependency of the app project.
And not just for TYPO3, the info about the packages and their version can be used in many ways to change the behavior of tasks.

[fe-hicking]

@t3easy This is great news. Sorry, I didn't catch that in my inspection of the issue. We'll happily test this once you feel up to getting feedback on it. I'm watching this issue, or if you want to open a fresh one for this followup, let me know. Many thanks for working on this, I think this will be a huge help for anyone creating global recipes like we do, where a wider range of versions/components can affect the workflow configuration. :-)

👍