The second call of magento:setup:permissions is skipped about capistrano-magento2 HOT 3 CLOSED

At first read I took what you wrote as implying that 3.6 changed something which caused the issue, but this is in-fact just a discussion where changing capistrano to diverge from default rake DSL behavior resulted in adding a warning to inform users who's procedures attempted to rely on an incorrectly assumed behavior (such as this one does).

Apparently I never noticed in the output that the permissions reset was never run the 2nd time, and 3.6+ now throws a warning. So…sounds like a bug fix is in order. I've confirmed that it doesn't run twice currently in the older version to prove my reading of the issue thread correct ;)

Now what I'm trying to figure out…

a) is it necessary to apply the permissions reset after generation of code / static assets

b) can it be run once, but after the generation is complete vs before and after

The advantage of doing it after is clear: everything has proper permissions. Running it before may be strictly necessary in some edge cases. The goal of this command is to have it lock down permissions to only be as open as necessary for M2 to run in most environments. That would include (most likely) read only permissions for everyone but the owner on things like generated static assets and code files, as well as the vendor directory.

from capistrano-magento2.

@davidalger Yeah, you are right that the behavior wasn't introduced in 3.6, but rather a notification was added explaining the behavior. Thanks for catching that.

I know there was a reason my initial Cap scripts reset the permissions twice, but I had a somewhat unique Linux user setup that I've since moved away from. I tend to think option b should work without issues in a standard setup. If we drop the first permissions reset and it causes issues, it should cause an atomic failure of the deployment, so the risk of making this change is fairly low.

If you'd like, I can remove the first permissions reset locally and test for a while and then submit it as a PR if I don't see any issues.

from capistrano-magento2.

This issue has been resolved and will be fixed in the next tagged release (to be tagged shortly).

from capistrano-magento2.