New maintainers wanted!
aslakhellesoy opened this issue · 17 comments
The creator of godog (@l3pp4rd) has stepped down as a maintainer and kindly donated the project to the cucumber GitHub organisation.
We're looking for one or more new maintainers. The tasks are roughly:
- Code! Scratch your own itch
- Keep dependencies uptodate
- Respond to GitHub issues/PRs in a timely manner
- Keep the CHANGELOG uptodate
- Make releases (Create git tags, update CHANGELOG)
- Keep the documentation uptodate
- Make the code habitable for new users and contributors
- Keep the CI running
If you are interested - comment on this issue!
I am willing to work as maintainer.
:raises hand:
me too
Thanks @gophersumit @jaysonesmith @lonnblad! I haven't had a look at the issues yet, but I did create #208 which is the first one that needs to be fixed. Anyone up for a PR for that?
Other ideas:
- Replace the gherkin parser with the official one - go mirror repo here:
- Add support for Cucumber Expressions - go mirror repo here
- Add support for tag-expressions - go mirror here
Let me know if you have any questions about how to get started!
(It might be worth noting that @charlierudolph has been working on Cucumber Engine. In an ideal world maybe these two projects could build on one another - I'm not sure.)
Just reading the README, it sounds like the Cucumber Engine could replace core parts of godog and that the main part of godog would then be output formatting
I don't know if there is concurrency support in Cucumber Engine, which exists in godog, at least on feature level and for simple progress and JUnit formatting.
I am traveling this week, but I have started to look at replacing the gherkin parser, the main issue for me is the introduction of pickles which is a nice addition, but means rewriting a lot. I have started with adding more test cases and I will push a PR for that later this week.
I'm happy to take on #208 as I'm personally more familiar with Circle than I am godog's code at them moment. I'll be working on both my go & dev chops, so feel free to toss the lower hanging fruit my way.
✋ I'd be glad to help!
I'd be interested in helping!
I will help also
🖐 I'm down to assist in maintenance as well!
That's amazing everyone! Once you have submitted a pull request and one of the existing maintainers have merged it you'll have access to the repo and can maintain away!
I looked at contributing to this project to improve concurrency but it wasn't possible without significant API changes. The current API/design does not allow for scenario isolation. I would like to donate my project to Cucumber org and encourage people to migrate. It has better API and it's based on cucumber-engine from Cucumber org (would love to re-use formatters and other Cucumber libs as much as possible as well) so it's a lot less to maintain.
@pranas Seeing as our Go implementation is still v0.x.x, API changes are acceptable, though we should be mindful about how they're made. My ultimate goal for the project would be for it to mirror the other versions as closely as possible while also making sense from an effective go standpoint.
While godog is currently the official Go version and already being used by a number of folks, we can certainly use your input and effort to make things better. :)
How's that sound?
@jaysonesmith It's great to see this project getting attention. We've used godog for a long time but eventually our test suite was big enough that we wanted proper concurrency. I briefly looked at what it would take to implement that with godog but even if I changed the API the underlying structure was working against me and the whole codebase was pretty big to grasp. You're probably more familiar with the code here and may have a better luck at it. In order to get proper concurrency, godog needs to isolate state per scenario basis (currently the state is shared per feature). I don't have a good plan on how to make it happen, it seemed easier to me to take cucumber-engine and put a thin layer on top of it.
godog needs to isolate state per scenario basis (currently the state is shared per feature).
Isolating state per scenario rather then feature is the default for all other Cucumber implementations.
In general what I would like to do is to divide the codebase into more packages and make the formatters in general simpler.
I would suggest moving the conversation regarding concurrency on scenario level to #180.
But, my 2 cents would be that for the formatters we have concurrency support for as of now, it wouldn't be a huge work to add concurrency support for scenarios. The question is how we want to handle BeforeFeature and AfterFeature.
The question is how we want to handle BeforeFeature and AfterFeature.
Why is concurrency essential? In most scenarios, where clear user steps are being handled, which are against a prepared environment, concurrency is not wanted.