Add support for having CE and EE structure separated

Example:

I heard @marin also has the same

This would be super useful to me.

Also WTF at "gitlabe_filter.rb/q" 😛

@rspeicher I think it someone tried to quit vim 😃

I prefer naming them ce and ee, but 👍 for the idea

👍

I hope there are no references from the gitlab-shell or gitlab-ci directories into what is now the 'gitlab' directory.

I never got around to this and now we have two MR's for this idea: !93 (closed) and !94 (closed) . @sytses points out in !93 (closed) that people could also clone GDK twice: once for CE, once for EE. I must admit that from a GDK maintenance perspective that looks like the most elegant solution to me.

In !93 (closed) I see two separate repositories directories and DB's for CE and EE. In !94 (closed), repositories is shared between CE and EE.

@dzaporozhets @vsizov @axil what are your thoughts on a 'clone GDK twice' approach?

mentioned in merge request !94 (closed)

mentioned in merge request !93 (closed)

people could also clone GDK twice: once for CE, once for EE. I must admit that from a GDK maintenance perspective that looks like the most elegant solution to me.

That is sure something to consider. The cons to cloning GDK twice is that postgres/redis/openldap data will have to be duplicated.

In !94 (closed), repositories is shared between CE and EE.

Nope, I also have the repositories dir separated ;)

---

Let's see the scenario where someone starts their work on CE and then in the middle of the day they need to switch to EE for some testing.

Different GDKs workflow

1. cd in the CE gdk
2. Run foreman for postgres
3. Update GitLab CE
4. Run foreman for GitLab
5. Do stuff
6. Kill foreman for GitLab
7. Kill foreman for postgres
8. cd in the EE gdk
9. Run foreman for postgres
10. Update GitLab EE
11. Run foreman for GitLab
12. Do stuff

Using Valery's workflow

1. cd in the gdk
2. Run foreman for postgres
3. Update GitLab CE
4. Run foreman for GitLab
5. Do stuff
6. Kill foreman for GitLab
7. Run switch ee
8. Update GitLab EE
9. Run foreman for GitLab EE
10. Do stuff

At its current state the switcher does not check for gitlab-shell/config.yml where the repositories and authorized_keys path should be unique to CE and EE. I know it's a WIP, just saying.

Using Axil's workflow

1. cd in the gdk
2. Run foreman for postgres
3. Update GitLab CE
4. Run foreman for GitLab CE
5. Do stuff
6. Kill foreman for GitLab CE
7. Update GitLab EE
8. Run foreman for GitLab EE
9. Do stuff

The only overhead I see in my approach is the cluttered Makefile, which I state in my MR as one of the caveats. Other than that, I've been using this for 2 weeks now, installed from scratch and been handling the updates via the Makefile without problem so far. Of course I am biased since this is how I'm used to work now :p

what are your thoughts on a 'clone GDK twice' approach?

@jacobvosmaer I am ok with cloning twice. But I am not ok with killing 2 foreman jobs (gdk and gitlab) in one directory and starting in another for switch from ce to ee and back. Also I don't want update workhorse and other components twice.

So ideally I would stick to solution that shares most of GDK but have own

• db
• gitlab
• gitlab-shell
• repos

@dzaporozhets It looks like if I add a switching of gitlab-shell then you would stick to my switcher :)

BTW @dzaporozhets What are you going to switch in gitlab-shell? authorized_keys? we don't use it in development kit, because we don't use SSH git operations, correct me if I'm wrong

@vsizov probably you are right. Its ok if we keep gitlab-shell shared

more over you can regenerate it at will, at any time.

In gitlab-shell there is also a repos_path variable, is it not used?

In my case it's not needed at all since I'm renaming a directory.

I don't like scripts that rewrite the working directory so much; for me cd is the ideal switcher.

What do you all think about the following ideas:

• GDK uses exactly one port (3000), which can be passed to make. You can have two or more GDK's running, one for CE and one for EE, with EE on e.g. port 3001. Switch using cd.

• 'dual head' GDK clones CE and EE by default, into gitlab-ce and gitlab-ee, and starts two gitlab-workhorse processes, one on 3000 (CE) and one on 3001 (EE)

I prefer 'single head' approach where GDK only uses port 3000 (or whatever number you want). This can be done because gitlab-shell now also supports Unix sockets.

GDK clones CE and EE by default

There are lots of contributors that don't want to work on EE code.

@vsizov I agree. My preferred solution is to make it as painless as possible to have to (isolated) GDK directories next to each other.

In !98 (merged) GDK is changing to use only one Procfile, with only 1 port. If you want to also work on EE: clone a second GDK, change 3000 to 3001 in your Procfile, start it, done.

@jacobvosmaer awesome

Not having this finished hurts productivity https://gitlab.slack.com/team/zj

@zj can you finish this if you get it to work using https://gitlab.com/gitlab-org/gitlab-development-kit/issues/40#note_3208550 ?

@sytses Ill set this up tonight and will try to create an MR in the coming days.

@zj great

@zj ping me on slack if you need help or have feedback. Should work better than this issue discussion.

@sytses FYI that slack link you posted only shows my private chat history with @zj; that is probably not what you wanted me to read.

Further improvements in !117 (merged)

Since !117 (merged) we have a recommended procedure to have EE and CE GDK's side by side. Closing this.

https://gitlab.com/gitlab-org/gitlab-development-kit/blob/master/README.md#gitlab-enterprise-edition

Status changed to closed

@jacobvosmaer thanks for fixing this, sorry for posting the wrong slack link

mentioned in issue #146