- Common enhancement tasks
- Common maintenance tasks
- Build and test your enhancement
- Submit your enhancement for review
Contribute to Omnibus GitLab
Common enhancement tasks
- Adding and removing configuration options
- Adding a new Service to Omnibus GitLab
- Adding deprecation messages
-
Adding an attribute to
public_attributes.json
-
Adding a
gitlab-ctl
command
Common maintenance tasks
- Upgrading software components
- Patching upstream software
- Managing PostgreSQL versions
- Upgrading the bundled Chef version
- Deprecating and removing support for an OS
- Adding or changing behavior during package install and upgrade
Build and test your enhancement
Submit your enhancement for review
Merge request guidelines
If you are working on a new feature or an issue which doesn’t have an entry on the Omnibus GitLab issue tracker, it is always a better idea to create an issue and mention that you will be working on it as this will help to prevent duplication of work. Also, others may be able to provide input regarding the issue, which can help you in your task.
It is preferred to make your changes in a branch named \<issue number>-\<description>
so that merging the request will automatically close the
specified issue.
A good merge request is expected to have the following components, based on their applicability:
- Full merge request description explaining why this change was needed
- Code for implementing feature/bugfix
- Tests, as explained in Writing Tests
- Documentation explaining the change
- If merge request introduces change in user facing configuration, update to
gitlab.rb.template
- Changelog entry to inform about the change, if necessary.
- Go to Settings -> CI/CD.
- Expand Runners settings.
- If shared runners are not enabled, click on the button labeled Enable shared Runners.
Write tests
Any change in the internal cookbook also requires specs. Apart from testing the specific feature/bug, it would be greatly appreciated if the submitted Merge Request includes more tests. This is to ensure that the test coverage grows with development.
When in rush to fix something (such as a security issue, or a bug blocking the release), writing specs can be skipped. However, an issue to implement the tests must be created and assigned to the person who originally wrote the code.
To run tests, execute the following command. You may have to run bundle install
before running it:
bundle exec rspec