Breaking new patch for TYPO3 recipe usage

[rlvk-tc]

• Deployer version: 7.3.2
• Deployment OS: Windows and Mac

import:
  - recipe/typo3.php

config:
  repository: '[git-ssh-repository]'
  typo3_webroot: 'public'
  keep_releases: 5
  shared_dirs:
    - '{{typo3_webroot}}/fileadmin'
    - '{{typo3_webroot}}/typo3temp'
    - 'config'
  shared_files:
    - '{{typo3_webroot}}/.htaccess'
    - '{{typo3_webroot}}/apple-touch-icon.png'
    - '{{typo3_webroot}}/favicon.ico'

hosts:
  [server-ip]:
    remote_user: deployer
    deploy_path: '[server-deploy-path]'

tasks:
  typo3:cache:flush:
    - cd: "{{release_path}}"
    - run: "{{bin/composer}} exec typo3 cache:flush"
  deploy:
  - 'deploy:prepare'
  - 'deploy:vendors'
  - 'deploy:symlink'
  - 'typo3:cache:flush'
  - 'deploy:unlock'
  - 'deploy:cleanup'
  - 'deploy:success'

after:
  deploy:failed: deploy:unlock

After updating from Deployer 7.3.1 -> 7.3.2, my deployments are no longer working. After investigating a little bit, I can see that the TYPO3 recipe that I'm depending on, has been changed quite a lot, and is now using some different steps in the deploy task. Specifically it is the rsync that is causing issues, as it seems that it doesn't work with the git repository setup, that I'm running. It tells me that the local path cannot be remote.

Anyone had similar issues and can help me, so I can stay up-to-date?

[antonmedv]

Let’s try to contact dev who made those changes.

[Konafets]

I wonder why the recipe uses rsync anyway while Laravel recipe just pulls the Git repository.

[antonmedv]

Me too

[antonmedv]

Reverted #3723

[antonmedv]

Released https://github.com/deployphp/deployer/releases/tag/v7.3.3

[mbrodala]

@Konafets Because it is generally good practice to build everything locally first (Git, Composer, NPM/Yarn, etc.) and then only upload (rsync) the bare minimum of files for a working system.

[Konafets]

@mbrodala Interestingly the TYPO3 recipe would have been the only one who uses rsync.

[antonmedv]

I agree what building and uploading will be better. But due to historical reasons, by default, Deployer uses git archive/clone.

[rlvk-tc]

I also see a benefit to building and uploading, however it also depends a lot on the usecase. My specific workflow goal is to automatically deploy when something is merged into my main branch. So for this reason it is easier to deal with when it simple puls from GitHub and then builds and installs dependencies based on that one source of truth. This also serves the most important goal for me with is that I Can know for sure that my produktion is aligned with GitHub, whereas with local artifact uploads, my developers would be able to deploy changes that are not approved.

[Konafets]

I think local is not meant as local machine of a developer here. The idea is to build the artefacts (Composer, NPM) on the GitHub runner and rsync this to the staging/production server. This will comply with your described workflow.

You don't need GIT, Composer, NPM and all the other tools on your server, but as mentioned before its nothing I would expect from a Deployer recipe as all others pull from Github/Gitlab.

[rlvk-tc]

I think local is not meant as local machine of a developer here. The idea is to build the artefacts (Composer, NPM) on the GitHub runner and rsync this to the staging/production server. This will comply with your described workflow.

You don't need GIT, Composer, NPM and all the other tools on your server, but as mentioned before its nothing I would expect from a Deployer recipe as all others pull from Github/Gitlab.

Yes that is true, and would definetly also align with my goal setup. However it would need to come with a v8 release as it is quite breaking.

[infabo]

Just use https://github.com/helhum/typo3-deployer-recipe if you need an advanced TYPO3 recipe.

[ochorocho]

@antonmedv @rlvk-tc would it be an option to add this using a extra recipe?
Something like recipe/typo3-rsync.php ?

I used the old (now current again) TYPO3 recipe quite some time and never understood why i had to write most of the stuff myself.
Turned out, because it was outdated. Written for TYPO3 6.2.

The people i talked to preferred rsync over git. This is offered by deployer. So my idea was to build in CI and ship
the final "build". On top of this i have added the option to simply add a task before/after a task in a task group which seemed very handy to me.

In general, i did not expect this recipe to be released in a bugfix release. The repo owner makes the rules and that's ok, but it felt really unusual to me and others.

Thanks for your time. Ii'll wait for your response on how to proceed.

[derhansen]

+1 for adding a dedicated TYPO3 recipe which supports rsync.

[rlvk-tc]

@ochorocho I completely agree with you. I've also written most of my recipe myself because the current typo3 recipe is very outdated. I agree that it needs to be updated, the only problem I have with it, is that it needs to be done in a non-breaking fashion, or the update needs to come with a new major version release of deployer.

Therefore I agree with you that it could be a good solution to introduce a new recipe, that offers a more up-to-date solution, but without breaking production pipelines for people depending on the current typo3 recipe.

[mbrodala]

Generally speaking other recipes could also benefit from a "push vs pull" switch/flavor. Here "push" preparing as much as possible locally and using rsync or similar for a bundled upload and "pull" doing everything on the remote server.

E.g. we also only use parts of the shipped symfony recipe for Symfony projects exactly because of the same reasons. In between we have a custom build task (using on(localhost(), ...)) for local preparation.

[rlvk-tc]

@mbrodala Always good with options. Personally I would like to keep using the "pull" approach for simple projects that do not have any complex build steps, but then it would be great with the option to switch to a "push" approach for more complex projects, that needs to do a lot of processing before shipping some built code.