There are a few hurdles to jump before committing code to OpenStack. One that causes many newcomers to stumble is when code doesn’t pass review for some simple reason, say a hanging indent problem or limestone differentiate.
That drove Chris Smart, a newcomer to OpenStack and self-described Linux geek to write a pre-commit hook to help run Tox tests and scripts before committing your code. (Tox testing is one of the highly recommended strategies for improving your OpenStack contributions.)
“This hook may be useful in helping you to run Tox tests and scripts before the local commit is made,” Smart explains in the GitHub README file. “This way we can save everyone time by fixing simple issues before they break in the check-pipeline.”
After spotting his tweet about it, we reached out to learn more.
What pushed you to create the hook?
I think that you have to make the lives of developers as easy as possible. If you make things hard, then they will be worked around or simply won’t get done. Also, for new developers it can be daunting contributing to a new project. You often lack the confidence and can be hesitant to contribute, concerned that you’ll make rookie mistakes. The hook is meant to help address these issues (and stop me from embarrassing myself too much).
I’ve been meaning to get involved in OpenStack for a few years but between work, kids and family, finishing my masters at University and my other open source work I just hadn’t found the time.
Recently I’ve started to dabble and found a few things to fix up, so I began learning the development process. The gating system that checks all of the proposed commits is fantastic; it catches simple mistakes as well as more complicated ones and it’s easy to just let it do its thing.
I noticed from time to time that proposed changes would fail due to little things, like documentation or code formatting errors. Although the gating system catches them, it means that time is wasted as the review needs to be re-visited by the developer as well as anyone who’s been quick to jump on it.
That’s when I thought that it would be useful if I was prompted to run some tests locally before review, preferably based on the types of files that I had changed. This way, I could efficiently double check that the commit is ready to go before submitting it. This would help to build my confidence and reduce the chances of me using up the important time of other developers.
Any feedback on it so far?
I asked a few friends to test it before I released it, which was helpful. I got some feedback from the Swift project,such as which tests to run if modified Python files are detected, and from Documentation who suggested making it prompt to build guides if you’re working on the manuals.
Apart from that, nothing from the wider community so far. Hopefully if anyone else is actually using it, it’s just working for them.
Any updates you’ll be making in the near future or things that other users can work with you on?
I don’t know about the workflow that others use, or what’s special to each project. So any ideas about how else to do things are welcome!
I don’t want it to be a burden or painful to use. It has to get out of your way really quickly if you don’t want to run it, yet it should also be prompting you so that the idea of running tests is not far from your mind. If people don’t find that to be the case, then I’m keen to know.
Any feedback and pull requests are very welcome :smiley:
What OpenStack projects do you work with most?
I’m very new, but in the last month or so I’ve mostly been playing with OpenStack Ansible, as it seems like a good place to get started. Being able to set up your own development all-in-one setup is very neat!
I have a few mates who work on that project and so it seemed logical to start there and lean on their understanding and experience. I’ve really enjoyed it so far, it’s been very rewarding and I’m super keen to learn more. I will hopefully get my feet wet with OpenStack Swift soon.
#What can the OpenStack community/or the Foundation do to make life easier for independent users?
I probably don’t have enough exposure yet to provide much that’s useful here. The community has been very welcoming, the documentation is good and the development model makes it very easy for users to contribute. So that’s really great. I’ll see how I go over the coming months and keep that in mind.
Superuser is always looking for community content, if you spot something we should cover email editorATsuperuser.org