New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issue with setup:di:compile #29
Comments
Hi @stu177 Could you execute the command in verbose mode You can also try adding the following in your
If after that, you have the same issue. Please also copy the verbose output here, so we can compare it. |
Hi @jalogut , Thanks for the response and help. I've just ran it with Here is my output from the
On a slightly different note, do you know what's the best practice with this deployment script to handle sensitive config values on the production server? I've read through the Magento Docs on it but it's not very clear on how to actually implement this. Update: I've just had it happen again with Update 2: So it's not intermitted but fails on the first run then succeeds on the second run. This seems to do the same every time, fails once, then runs. Update 3: The command it fails on:
If I run that by itself, it runs everytime without a problem. |
Ok so after looking into this, I think I've figured out what is going on but my knowledge of composer and autoloaders isn't great so I might be way off. It seems it has something to do with composer messing with the In the composer.json there is the PSR-0 section: "psr-0": {
"": [
"app/code/",
"generated/code/"
]
}, If I remove I think what is happening is it's including the I can replicate this by just running these two commands from the build process one after another:
Is there an issue with removing |
Ha, I had exactly the same issue @stu177 . It would fail every other deployment. I worked around it by running It's only happening on https://buddy.works/ for me, because they reuse your container for successive deployments unless explicitly told not to. On projects running Bitbucket Pipelines I don't have this issue since they always create a new container and just hydrate Composer cache. I think deleting generated directory is a good workaround because you're not speeding DI compilation up anyway by having compiled DI before. It just overwrites it every single time. |
@erfanimani Ah yeh, should I be doing this instead of removing @jalogut Any thoughts on this? Should this be changed in repo? |
@stu177 to be honest, I actually have no idea what removing |
Hi @stu177 and @erfanimani Glad to see that you are looking further into this issue. I investigated a little a bit about the reason of this
I honestly never faced this issue because we do not have On the other hand, it would be great if you continue looking on the issue and find a better solution. Unfortunately I do not have much time now for that. I hope these insights help you a little bit ;) |
Hi again guys, After reading again your comments, I think @erfanimani is completely right here:
Could any of you maybe create a PR that does a |
Thanks for coming back to this issue @jalogut — I can create a PR Monday at work. I'm not entirely sure what the best approach would be though. Are you OK with me adding a new invocation after this line? https://github.com/jalogut/magento2-deployer-plus/blob/master/recipe/magento_2_2.php#L28 Otherwise I can add it directly to the |
Hi, Yes, let’s add a new invocation there for now as the issue seems to happen only when using the build task. If we notice more issues in the future, we can add it into the |
…loader is created.
Fixes #29: Generated directory is now cleared before DI compilation.
FYI, found the root issue here and reported it to Magento (see reference link above). |
Hi @scottsb thanks for the info and for taking the time to report it to magento ;) |
When
magento_dir
is set to'.'
in my deploy.php, if I run dep build I get the following error:If I set the
magento_dir
to an absolute path, it works for the local build but when pushing to production, this path is incorrect and breaks deployment. If I then change it back to'.'
it works for production.It seems like it should just
'.'
for local but it throws theClassLoader.php
error. Any ideas?The text was updated successfully, but these errors were encountered: