Open marcoscano opened 2 years ago
I think the only reason is that no one had this need so far ;-) Feel free to work on it if you need it, no reason we don't merge it.
@vbouchet31 thank you for your prompt response! I just wanted to make sure I'm not reinventing the wheel... :)
I'm finding that whenever a content staging (prod -> dev for example) happens, the destination environment gets changed to the code ref that is on prod. Is this the expected behavior?
So for example, if I always want to have DEV on the main
branch, and from time to time downsync a single site from PROD to DEV, that makes DEV change after the DB is synced town to whatever code tag was on PROD. I don't understand why this happens, but if there isn't really a way to avoid it, a command to switch back the code to main
would be handy, so it could be included in a post-staging-update
factory hook.
Does that make sense?
Thanks!
Ah it may actually be one difference between the v1 and v2 APIs for content staging. When doing content staging via the UI, the checkbox "Wipe target environment" is responsible of the behaviour. If it is not checked, then only the selected sites are staged, existing sites on the environment are kept (unless they are selected for staging of course), the code is left unchanged. If the box is checked, all the sites are trashed, code is restored to PROD version and selected sites are staged. On the projects I worked on using ACSF, we were using "hard stage" for a staging with wiping, "soft stage" for a simple stage without wiping (so it may make our discussion shorter ;-) ).
If that is really your need, it may be better to invest time on switching the staging API endpoint to v2 and expose the additional option.
Ah, that makes sense. I see now more clearly the differences in the endpoints, and yes it does make sense then to just improve the content stage command to use the v2 endpoint and expose that checkbox behavior there too. Thank you! I'll start working on https://github.com/acquia/acsf-tools/issues/143 then.
In any case, it's possible our project might need a command to switch code in the future, so I might come back to this issue at some point :)
Thanks again!
Is there a reason we don't have a command to trigger an environment update (code switch), using the
/api/v1/update
endpoint?I can work on a proposal for this, but wanted to have initial thoughts on why this hasn't come up yet.