We need a prototype branch (aka visiontype) to show how we envision integrating Koding with GitLab so a developer can start with an idea and create code to realize that idea.
Now as a developer on the team seeing the issue in the sprint view, I decide to pick it up. I'll drag it to Doing first and then click through. I'll assign the issue to myself to let the team know that it's claimed. Then let's kick off Koding to write code directly in Koding's sweet online IDE; using the full power of a development environment that happens to be running in the cloud.
Since this is a new project, it's a nearly blank repo. But of course my fictitious company has boilerplate starter applications I can copy, so I'll start from there.
And then there's the new idea itself. I'll just paste this in to save some time. Great, now we're done. If I got stuck, I could turn on "Start Collaboration", share the link, and someone else on my team could peer program with me.
Review with Koding
Also, Koding isn't just an IDE. It's a full development environment. That means I can run anything from the command line that I would do on my laptop. Let's go ahead and run this app we just created. We'll install all the required modules. Now start up the web server. Great, now let's look at the app. Pretty exciting, isn't it? Even better, any other developer on the team could do the same thing, starting where I left off. It can also be used to show the running app to other team members such as product managers that need to review the results without caring about the code itself.
Merge Request
So everything looks good, let's check in our changes and push them back to GitLab. Now let's switch back to GitLab. Here we see it's detected the new branch and offered to create a Merge Request for us, how nice of it. Let's go ahead and do that, creating the merge request. It knows by the branch name that it closes issue #1 (closed) and adds that message automatically. Let's add a message and save this.
How does this look? Does it look feasible? Does it fit with current v0.1 of the integration? Some hand-waiving is acceptable. For example, I'm going to skip all the configuration of a stack and assume a reasonable default stack came with the default installation. And that somehow Koding automatically got creds to the Openshift cluster GitLab was installed on.
@annabeldunstone From what I understand, the current MR for Koding doesn't add a button to Issues, just to MRs. We might need to hack in a hardcoded button into Issues for the demo.
@markpundsack I can make that change into the issues as well, I'll let you know once I've done something working. As I noticed there we may need to provide an option to user to test target issue on a specific branch, we can ask for it by listing the current branches or we can find a better way while creating the issue we can ask user to pinpoint a branch instead.
@gokmengoksel When you click on "New branch" from an issue, it prefixes the branch with the issue number. Perhaps it's enough to create/detect that pattern? Alternatively, you could look for linked merge requests since issues know which merge requests will close them.
@gokmengoksel FYI, when I was going through my demo flow, I started from a completely empty project, which normally blocks the Run in IDE button from appearing. I ended up hacking it by adding a README first, so the repo wasn't empty, but wanted to throw out that potential use-case, which is to start the IDE before there's any code at all, and have someone rails new or equivalent from the IDE's terminal to create the project. Might be pretty uncommon, but thought I'd mention it.
@markpundsack for repositories without .koding.yml file on head I'm hiding the button but I'm planning to handle that case as well by creating a sample stack template on Koding side if such requests comes up, once I implement that part we can show the button on every states. But for now it should be the correct behaviour.