Closed zbintliff closed 5 years ago
To add, digging through the code I see that it picks randomly here. Would you be open to feature requests to limit that?
I'd be open to a feature request to specify the port itself, and default to randomly picked as is it's current behaviour.
Awesome I'll whip up a PR. Can you add some color though? We have only done consumer side (daemon.MockService) but hope to do producer side well. As far as I can tell with the code, another listener is only stood up when dealing with consumers. Is this right?
Gave it an attempt in #47
Would love to get your feedback on #49 before I go through and fix all the tests.
Thanks @zbintliff, I've been away last week but will look over in the next few days.
Hope you had a great time away, closing as this is resolved.
I sure did. Thanks for you patience in getting this one in.
You're currently wrapped in a beta release v0.0.10
. I'll see how this goes over the next few week or so and bump it to latest if all good. This will include updating documentation etc.
Also, I noticed here it says dsl/mock_service.go
fails gofmt -s
but when I write locally and diff there are no changes. Can't figure out what is wrong with it.
And a pre-release is awesome because we can build our jenkins pipeline around it for our clients still.
Yeah, I don't get that either. Strange.
I just realized I did all of this so I could expose a set of known ports on the daemon/mockservice. Then i wrote it to bind to localhost :/
Pull request welcome ðĪŠ
Have to apologize. Seems my PR didn't really solve any issue. The feature works, you can limit the ports the mock servers are spun up on. But it only works if daemon and mockservers are on localhost with the process running the dsl.
I have some thoughts on how to fix #1 and that involves the daemon determining the port. The DSL just passes the whole allowed port string through, the daemon determines the port and returns it as part of the server again.
I just wanted to step back and run some things past you before I dig into that. Thinking of making the following three changes:
No worries.
You make some good points, I'm happy for both of those suggestions to be done - go for it.
That being said, we need to move away from the Daemon at some point anyway. I'm going to expedite the implementation options of removing it and will document it over in #31. Your thoughts would be much appreciated on that one.
@mefellows Good job with https://github.com/pact-foundation/pact-go/tree/feat/daemonless! ð I managed to dockerize setup and run it without a daemon (consumer part so far).
That's fantastic news, thanks @springerigor! Please, any further feedback you have is much appreciated.
Hey @mefellows, thanks for the good work ! I'm currently implementing contract testing in a golang codebase and I stumbled around the same issue when trying to run pact-go inside Docker containers. I'm currently trying-out your feat/daemonless branch, and it seems to work like a charm ð Managed to run both my consumer + provider tests with it ! Looking forward to have it released, do you have any ETA for that ?
I'm not sure I can find the time to make code contributions, but here's some feedback I have so far with using pact-go with Docker:
golang:1.9
, the uname -i
command returns undefined
instead of x86_64
, resulting in a failure of the install script. This is probably an issue for https://github.com/pact-foundation/pact-ruby-standalone but as a workaround, here's the Dockerfile is used to make it work:
FROM golang:1.9
RUN cd /opt &&\ curl -LO https://github.com/pact-foundation/pact-ruby-standalone/releases/download/v1.43.0/pact-1.43.0-linux-x86_64.tar.gz &&\ tar xzf pact-*.tar.gz
ENV PATH="$PATH:/opt/pact/bin"
WORKDIR /go/src/path/to/your/sources COPY . .
CMD go test -v ./...
- Other issue I encountered is related to error printing. At first, my `Dockerfile` was not setting-up the `PATH` properly and my tests were failing to find the `pact-mock-service` program. However, the only output I had was something like this:
=== RUN TestConsumer exit status 1
It took me some time to figure-out the issue was that here https://github.com/pact-foundation/pact-go/blob/feat/daemonless/client/service_manager.go#L147, the error message was not actually printed. This is probably due to some buffering not being flushed before the program exits. So maybe not using `os.Exit(1)` or flushing stdout would help here.
Appart from these minor issues, I managed to run my tests without needing to run a daemon, which is awesome ð
Thanks for this @gaelduplessix that's awesome. That os.exit
is something to look at. Not sure we need it anymore.
We're probably looking at making it real in next month or two. Feedback on the API and install are the main things we're waiting on, aside from a good tidy up of the code (it's very POCy at the moment as we explored the API).
Will take this feedback onboard
Closing this issue for three reasons:
os.Exit()
in service manager (see c2dcd782)
Is there any way to limit which ports interactions can map to? i.e. main server is 6666 and then 20100-20200 are used for interactions?
Right now we just expose every port over 1024 in our container but would like a little more constraints than that.