Skip to content
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

Update to PHP 7.4 #1164

Merged
merged 1 commit into from
Apr 2, 2020
Merged

Conversation

markjaquith
Copy link
Contributor

fixes #1163

I left the PHP 7.2 service code in there, as well as adding new PHP 7.3 service code. I figure it doesn't hurt to keep it (it's just a few lines), and if anyone is upgrading from a 2018 version of Trellis to the PHP 7.4 version, it'll handle them leapfrogging PHP 7.3 completely.

@swalkinshaw
Copy link
Member

I'll give this a try tonight but looks great 🎉

Copy link
Collaborator

@tangrufus tangrufus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎉 Looks good on my server.

Note: I didn't test on vagrant.

@markjaquith
Copy link
Contributor Author

Didn't test on vagrant.

I did! Patch applied cleanly against my /trellis/ directory, and I ran vagrant provision. No problems at all.

@tangrufus
Copy link
Collaborator

I mean I didn't

@swalkinshaw swalkinshaw merged commit 6959e3e into roots:master Apr 2, 2020
@swalkinshaw
Copy link
Member

🎉 thank you

@axi
Copy link

axi commented Jun 18, 2020

I also updated my /trellis and ran ansible-playbook server.yml -e env=staging

Website (test server ;-) went down for few seconds when ansible ensured php7.3-fpm is down...

Shouldn't that test (ensuring php7.3-fpm is down) be called at the end of provisioning as https://roots.io/docs/trellis/master/remote-server-setup/#re-provisioning states that

Re-provisioning is always assumed to be a safe operation

Note sure I should create an issue on that. Any idea to prevent that on production ? Just comment that portion should do I think

@swalkinshaw
Copy link
Member

@axi you mean everything worked properly but php7.3-fpm service was still running? Nginx will be pointed to php7.4-fpm at that point though so it couldn't actually cause any issues? But yes, it should be stopped manually ideally.

Re-provisioning is always assumed to be a safe operation

This statement is slightly misleading I guess. It's assumed to be "safe" (non-breaking) if the changes themselves are safe.

@axi
Copy link

axi commented Jun 19, 2020

@swalkinshaw
On a running server, during re-provisionning, php7.3-fpm is shutdown before nginx config has been updated to point to php7.4-fpm, resulting in 502 error during few seconds. I thing shutting down php7.3-fpm at the end of provisionning should fix the short period where nginx still points to 7.3 but 7.3 is down. It's just a matter of order.
Update went well on every other points ;-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Update to PHP 7.4
4 participants