Feature request - What about hotfixes to live or to test envs?

[bob-hinrichs]

Granted this is complex because there needs to be a way to know the intention via the github source. For an example from real life, the github repo can have three branches mapped respectively to each of the three pantheon envs, and a push to the test branch=push only to test environment. This could merge back down to the dev branch automatically; or make it optional so that the developer merges locally to dev branch and can take care of potential conflicts (then push back to dev).

[stevector]

Hi @bob-hinrichs! Thanks for the suggestion. Yes, I could imagine creating a convention around tags or branch names on GitHub that then create the appropriate tag names on Pantheon to do hotfixes: https://pantheon.io/docs/hotfixes

I think if I needed to do a hotfix on a site using this orb right now I would take the multidev generated by a pull request and make the hotfix tags from that commit in the Pantheon repo.

Do you have a site or project that needs this? Have you previously needed to hotfix an orb-built site?

[bob-hinrichs]

Thanks Steve, I am currently working on a circleci config that does this based on a branch that is pushed. I can send it to you once it is at least proof of concept in case it could be useful.

[bob-hinrichs]

circleci.zip

Here is our current code that uses three local branches (master, qa and prod), such that, for hotfixing live, you would check out 'prod', make your fix, push it, then merge it down into qa, and master. Deploying a release to test, you merge master into qa and push. Deploying to live, you merge qa into prod and push. This assures that any merge conflicts are handled locally, eliminating the possibility of merge conflicts on circleci. It is also procedurally easy for engineers to have all three branches available via a straightforward switching/merging of git branches, rather than checking out a tag into an unattached head state.

[stevector]

ah, so if I fully understand the motivation here, you're more looking for a workflow where all deployments are made through specially named branches. And accommodating that on Pantheon requires the hotfix workflow. So the hotfix workflow becomes the normal workflow, at least for a given project/team.

If so, I'm reluctant to build that workflow into this orb, at least until there's a stronger signal that many teams would want to do that. It was a Pantheon product decision not to align the three environments with separate branches, and instead have everything flow though master/tags.

That being said, this still could be done in your own custom orb if you want to speed to reimplementation across projects. Making a new orb isn't much more complicated than making project-specific config.