Workflow for working with local and shared targets in a team

[marktani]

Issue by kbrandwijk
Thursday Nov 16, 2017 at 13:29 GMT
Originally opened as https://github.com/graphcool/prisma/issues/1285

---

A graphcool service project contains a .graphcoolrc file, which contain the targets for a project. When working with multiple developers, it's great to share this file, so everyone is working with the same test/production services.

However, the .graphcoolrc also contains local targets. Those are specific to your local machine, and don't work when shared with other developers on the team.

The workaround is to remove the local target manually from .graphcoolrc, but then committing it to source control shifts the problem back to the first developer.

I don't have a concrete proposal yet for how to deal with this. Maybe local targets should be in a .graphcoolrc.local file or something, that would not be committed to source control?

[marktani]

Comment by vincenzo
Thursday Nov 16, 2017 at 14:30 GMT

---

Thanks for creating this @kbrandwijk. I am fairly new to GC, so I may have a limited view on things. However, the first thing that comes to mind is this: leave .graphcoolrc as it is, and handle the following exception differently:

No service with id 'cj9ttwnlb009h0150kg59sgb0' in account test@test.org. Please check if you are logged in to the right account.

Rather than issuing this as an error, you could issue an informative message, and then just create the service that wasn't found with the same id found in the .graphcoolrc file (if that's possible, of course):

The service with id 'cj9ttwnlb009h0150kg59sgb0' was not found. It will be created now.

Thoughts?

[marktani]

Comment by kbrandwijk
Thursday Nov 16, 2017 at 14:34 GMT

---

The problem about that is that when a new service is created, it also gets a generated id. Your approach would require being able to specify a serviceId when creating, which would require a lot more changes across the stack (both server-side and CLI).

[marktani]

Comment by vincenzo
Thursday Nov 16, 2017 at 14:41 GMT

---

I suspected as much. Then, separating the local targets out to a different file that is never checked into a repo seems to be the only alternative. Coming at this with a Unix-like mind, I would suggest that such a file for local targets could easily be living at $HOME/.graphcoolrc.local, where GC could store the references to all the local targets (across many services), rather than ending up with a .graphcoolrc.local for each of your .graphcoolrc. This way you also avoid the annoying issue of having to explicitly exclude the files from various repos.

[marktani]

Comment by kbrandwijk
Thursday Nov 16, 2017 at 14:42 GMT

---

These should be specific to the project, because a dev target on one project is not the same as a dev target for another project, and target names are not unique across all projects.

[marktani]

Comment by vincenzo
Thursday Nov 16, 2017 at 14:46 GMT

---

But the local target is always called local, isn't it? Maybe I am missing something, but I still think all local targets could be aggregated in a single file, whose content would look a bit like this:

local_targets:
     cj9vulbge1fmp01733782ivar: local/cj9ttwnlb009h0150kg59sgb0
     cj9wmccwo2mqh0148d71od6bu: local/cj9sswnlb009h0150kg59sgb1
... 
... 

Where the id I am using as keys are the production IDs related to that particular local target.
Messy? Wrong? :)

[marktani]

Comment by vincenzo
Thursday Nov 16, 2017 at 14:53 GMT

---

What if you don't store the local targets at all? I understand that when one runs gc deploy -t local GC looks at the CWD to understand what service to deploy. Assuming a directory for each service, it's safe that in a CWD there is only one service to deploy. Couldn't you then (not sure how, since I don't know the internals) do a check like this: "if there's a local service already deployed for this, then deploy there, else create a new one". Did I make any sense?

[marktani]

Comment by kbrandwijk
Thursday Nov 16, 2017 at 15:17 GMT

---

No, your local cluster uses the cluster name from ~/.graphcoolrc. The target name is what you specify when running gc deploy. So you can have:
dev: local/c3......
otherdev: secondlocalcluster/c3.....
local: othercluster/c3....
local: local/c3....

You're also not limited to one local target per service, so this all has to be explicitly stored.