testcontainers
feat: add Dex IdP module
What does this PR do?
Add a Dex module, similar to the already existing testcontainers-java module.
Why is it important?
This allows to test OAuth2/OpenID Connect authentication implementations.
Related issues
No issue was created for this so far.
How to test this PR
Hopefully the implemented tests and documentation is sufficient, if not, please let me know, so I can extend them 😊
Deploy Preview for testcontainers-go ready!
| Name | Link |
|---|---|
| Latest commit | d30095966050d517d37d85700707fadd55f36ced |
| Latest deploy log | https://app.netlify.com/projects/testcontainers-go/deploys/686273d97c59840009ee8185 |
| Deploy Preview | https://deploy-preview-3216--testcontainers-go.netlify.app |
| Preview on mobile | Toggle QR Code...Use your smartphone camera to open QR code link. |
To edit notification comments on pull requests, go to your Netlify project configuration.
![netlify[bot] avatar](https://avatars.githubusercontent.com/in/13473?v=4 "Published by a pub.dev verified publisher"){kind=small}
I'll change everything as you requested when I'm back from vacation, hopefully this will then at least guarantee a quick merge although I'll detest my own API then
Not sure why the pipeline now fails to be honest, I did validate golangci-lint locally and it worked, will check it in the upcoming days
@stevenh @mdelapenya I thought about this again and came to the conclusion that I will not progress with this PR or any other PR with testcontainers-go in the future.
I do understand that, you do what you think you must and I hope you understand that I have to do, what I must. I don't get any fun out of contributing to testcontainers-go anymore this way.
Even without further discussions and simply accepting all "suggestions" as change requests, every round of adopted changes only brought up another, the last one even without ANY change to the API of the package OR maintenance implications but - as I see it - purely a different taste of things.
If that is how you successfully collaborate with other contributors, great! But I'd have wished for a more efficient and focused way of reviewing to ensure consistency and quality without sacrificing individuality.
I wish you all the best
@prskr our main goal has always been and will always be to think in the "common good" for the project and the community first.
The take away after this for us is to revisit the contribution guidelines, because the design process of any software is continuously evolving, and they could be outdated soon. What we cannot do is to write down all the rules and patterns for each block in the project, as they would be outdated the next day a new pattern emerges. Our job as maintainers is to transmit that "tribal knowledge" in any manner: updating the docs (we seem to fail here?) or during the review (as we also failed here?). Of course, it never rains to everybody's desires (spanglish), so we perfectly understand your decision. We advised you to create your module, with your rules under your own account, as many other people do.
It's always hard to cut relationships with a project, so I really believe you did a pretty conscious decision.
