@nickchomey Thanks for the contribution! Since you're already on it, how about you also add that script, which runs the "debuggable" build? Basically, that would mean we have the template fully ready for debugging. make build-debug would create the following structure:

.
├── bin
│   └── conduit-connector-foo
├── conduit-connector-foo.sh

That way, you're fully set up for debugging!

Will do!

Actually, I dont see how this would work. The template just creates a repo for a new connector, and this PR just adds a debug build to the makefile.

But in order to use that debug build, you have to either copy or symlink it to wherever you have your conduit binary. You would also need to change the port number for each connector. I dont see how the makefile in a connector's repo could or should handle all of that.

What seems to be needed is better (official) documentation on how to set up a development environment for conduit and conduit connectors.

But in order to use that debug build, you have to either copy or symlink it to wherever you have your conduit binary.

Why would you need the Conduit binary, if you want to prepare a debug build for the connector? The idea that I proposed is basically this:
Makefile

.PHONY: build-debug
build-debug:
    go build -gcflags=all="-N -l" -ldflags="-X 'github.com/conduitio/conduit-connector-connectorname.version=${VERSION}'" -o bin/conduit-connector-connectorname cmd/connector/main.go
    # create conduit-connector-connectorname.sh

So it builds bin/conduit-connector-foo and creates conduit-connector-foo.sh. Then you copy the script and the folder bin/ to Conduit's connectors directory, and that's it. Conduit's binary doesn't have to be touched.

As for the port, you're making a good point! We could hash the connector name and get a number from it. That would give you the same port every time you build it and you can more easily debug it.

Btw, what I mentioned isn't a must-have for this PR, just a thought about maybe making it easier to debug a connector.

Good idea with the hash. I'll implement that and make the change you requested

The core team briefly talked about this PR and we decided to not include it in the template. The standalone connector debugging approach is really only useful for the core team when figuring out a communication issue between Conduit and a standalone connector. On the other hand, for the connector developer, it shouldn't make any difference if they run the connector as a built-in or standalone connector, so given that they are focused on the connector functionality, they might as well take the easy route by debugging it as a built-in connector (as you have noted yourself).

So that's why we decided to instead treat the original issue as a documentation issue, moved it to the conduit-site repo and we'll eventually create a guide for developers on how to debug a connector using the built-in connector approach. I hope that still addresses your concerns!

That makes perfect sense. I agree that testing connectors via a built in connectors is the right way to go, and no one in their right mind would opt for doing it via standalone.

Funny enough, I just remembered this issue/PR last night and intended to look at finishing it today. Good timing that you closed it now!