Allow deploy to pantheon to custom multidev given some conditions

[unclegcb]

On kmc-tester, the CI was set to trigger only for pull requests. I wanted to set up a demo multidev, so I created a branch and pushed it called "demo". CI did not trigger, as I had no pull request.

I changed that setting in Circle, and it built, but created a multidev called "ci-570", not "demo". It also triggered a lot of builds, despite there being only 1 commit on the demo branch, and the third of 3 ci processes failed.

This seems like unexpected behavior to me, but it's possible I'm misunderstanding the workflow as well, so this ticket can also just be for discussion.

[mariacha]

Yeah, you've got it right -- the system is set up to only make multidevs when you open a PR, and then the multidev will be called "PR-X".

This is because each Circle workflow performs many jobs, and a lot of them, including the Behat tests and VR tests, are run right on the pantheon multidev environment. I'm surprised to see that the Pantheon build tools try to fall back to the Circle job number if you don't have a PR number for it to attach itself to, because each job has its own number:

So the VR and Behat tests run on different Circle jobs so will try to use a multidev called "ci-578" which doesn't exist.

What's more, when you close a PR, your multidev will be deleted as well. What happens to the "ci-x" version of the multidev? I imagine it hangs out forever?

So in short, creating a branch with a specific name, not making a PR, and pushing that to a specific multidev in Pantheon isn't really supported by this workflow.

[mariacha]

@unclegcb We could change the behavior, of course. We could alter the .circleci/config.yml file so that it deployed to both a PR AND to some multidev given some conditions. If we decide it's a feature worth pursuing, the only trick will be preventing losing that with each new composer install. There's a section in the composer.json file that would need to be told to not pull from the upstream:

"km-collab-scaffold": {
            "excludes": {
                "post-install-cmd": [
                    "composer.json",
                    "composer.lock",
                    ".gitignore",
                    "README.md"
                ],
                "post-update-cmd": [
                    "composer.json",
                    "composer.lock",
                    ".gitignore",
                    "README.md"
                ],
                "post-create-project-cmd": [
                    "composer.json",
                    "composer.lock"
                ]
            }
        },

We could add

.circleci/config.yml

to the post-install and post-update hook and do whatever we wanted to that circle file.

I'm going to tag this ticket as a Nice to Have with the assumption that that's the task.

[mariacha]

So, proof of concept, https://github.com/United-Philanthropy-Forum/kmc-tester/pull/87 exists. You can explicitly pass the environment to your build script, if you don't want to use the default PR -> multidev behavior.

So what logic would we want to employ to create a "permanent" multidev? What makes sense? Some thoughts on options:

• If the branch name starts with "release", push to a multidev. So if we wanted to make a demo site, checkout a branch called "release1" from master, and make a PR for it against master. Merge any PRs you wanted to go into that multidev into release1 instead of master, then merge release1 into master when the release is approved. -- I'm not sold on "release" to be the word. What do people think?
• Alternatively if the PR has that line in it, push it to that multidev (i.e. ask the developer to make that decision).

If the goal is just to have a non-master branch where groups of work could be packaged and reviewed, it seems like the first option would work to me. If there's some other use case that I'm not thinking of, we can do it differently.

And now that I'm thinking this through, we could be more clever too. If a pull request is made to go to a branch with release in it, we could pull the database and files from that release multidev into the "pr-123" multidev instead of using the "dev" multidev, as a starting point. That would probably help with the struggle people are having with their pr- multidevs not having useful, persistent information.

@wxactly @unclegcb what do you two think?

[wxactly]

For the option like https://github.com/United-Philanthropy-Forum/kmc-tester/pull/87 where we edit the config.yml in our feature branch, does that mean we would need to remember to roll that change back before the branch was merged? Or would these just exist for the purpose of mapping to multidevs?

[mariacha]

Great question. Yes, and it's not ideal. We would need to not commit that to the master branch. But, as is, that config file gets reverted with every composer install, so the chance of it being in the master branch for long is small.

I don't think it's a great long-term solution, but it does work out of the box right now, and can be a quick hack for special cases.

[unclegcb]

I kind of like the keyword approach. We already talk about "release candidates" with the forum team -- what if the key were just having a branch that starts with "rc"? That leaves enough room for some more flexible usage: "rc-sheer" could just be sheer's develop branch. Alternately, I guess we could have multiple keywords. I like having a "develop" multidev, for example.

[wxactly]

+1 for rc-! Love it

[mariacha]

Confirmed that if you use the custom TERMINUS_ENV and then close that PR, your mutlidev stays open. Note that the Issue 12 multidev still exists: https://dashboard.pantheon.io/sites/e27a88f9-ee05-4e09-afd0-796c7722d135#multidev

That was created here: https://github.com/United-Philanthropy-Forum/kmc-tester/pull/87

Those multidevs get cleaned up the next time the "deploy to Pantheon" job gets run, so I made sure it was working by merging in https://github.com/United-Philanthropy-Forum/kmc-tester/pull/89 then rerunning the circle workflow for https://github.com/United-Philanthropy-Forum/kmc-tester/pull/80.

This did what was expected and deleted the multidev for "pr-89" but left the "issue-12" multidev existing. So going forward with the assumption that we can use the rc- format.

[unclegcb]

That's exciting: doesn't sound too painful!

[mariacha]

New investigation done on https://github.com/United-Philanthropy-Forum/kmc-tester/pull/92

This allows you to pull the database from the branch that a PR is based against.

The next thing to try to get working is that if you merge something to rc-x it will deploy to pantheon regardless of an open PR. That's proving difficult because in order to do it we'd have to either:

1. Turn off the "Only build PRs" option on Circle and then rework the build_deploy_and_test to only build on PRs for any branches OTHER than, like, rc- -- this is maybe fine if we're only going to do it for kmc-tester, but it would mean an extra step for any other repo. Do we think other sites will want this behavior?

2. Give up and require folks to open an rc- -> master pr if we want to see builds on to it.

I suppose regardless, I need to set up the functionality that builds a multidev based on the name of your branch. Going with option 2 to start, then seeing how much further work would be needed for option1.

[mariacha]

This is working here and on the kmc-starter kit. We should chat about the best place and way to document this workflow. @unclegcb do you have thoughts?

[mshaver]

Hi @mariacha, I'm moving this to the Documentation lane and assigning you. If we're documenting other dev workflow situations in the wiki, I think that makes sense to document there as well.

[mariacha]

I added proposed release documentation here: https://github.com/United-Philanthropy-Forum/km-collaborative/wiki/Crafting-a-Release

@unclegcb what do you think? I am considering doing a checklist that could be attached to the release ticket as well, like we do on our deployments, but I wanted to get initial feedback frst.

[unclegcb]

That documentation has been great, and I've also done a lot of inline polishing. The RC workflow has been great so far. I think we can close this ticket and make improvements as we go!