After an internal call for help to take over software.opensuse.org deployment, I spend some time studying the code in order to find out what would it mean to take it over.
The main reason was a PR from the community that has not been merged, and deployment depending on internal SUSE employees. I discovered (or at least I did not found evidence of the contrary), there is no need for this machine to be internal, as it uses the API.
On the other hand, the deployment is using rpm for gems, and it is quite tied to the setup of a virtual machine, all these things are nice for a sysadmin but not so nice for a developer.
I forked it, merged the new theme and fixed a few bugs: repo On the way, I also enabled it to be deployed on PaaS: Heroku, SUSE CAP (Cloud Foundry), etc.
So the goal of this project would be to:
- Find if the stakeholders would be ok with a different deployment mechanism. At least something not sysadmin-centric.
- If this is not feasible, still see if deployment can be improved. nginx, no rpm for Gems, etc.
- Build a small group of people willing to learn by taking over this piece.
- If all goes good, take over the responsibility of this component.
software.opensuse.org has been refactored, cleaned up, updated to Rails 5, added tests, etc.
The testsuite runs on every Pull Request, and we are very very close to automated deployment.
Looking for mad skills in:
opensuse rails rubyonrails ror ruby web webapps
This project is part of:
Hack Week 16
www.opensuse.org is the single most accessed pa...
Right now, we have diff...
Bicho is a ruby gem to query bugzilla. I have r...
Currently externaltools is deployed manually wi...
I have been building an archive of the x86_64/d...