-
-
Notifications
You must be signed in to change notification settings - Fork 109
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Running Pact-Go Daemon in a Container #46
Comments
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 |
Also, I noticed here it says 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! 👍 |
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 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:
FROM golang:1.9
# Install Pact binaries
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"
# Copy sources
WORKDIR /go/src/path/to/your/sources
COPY . .
# Run all tests
CMD go test -v ./...
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 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 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:
|
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.
The text was updated successfully, but these errors were encountered: