- Setting up development environment
- Understanding the architecture
- Writing tests
- Merge Request Guidelines
- Validating changes to a single software dependency
- Testing changes during install/upgrade
Omnibus GitLab developer documentation
- Development Setup
- Omnibus GitLab Architecture
- Adding a new Service to Omnibus GitLab
- Creating patches
- Repositories, branches and CI pipelines
- Release process
- Building your own package
- Building a package from a custom branch
- Adding deprecation messages
- Adding an attribute to
- Adding a
- Managing PostgreSQL versions
- Upgrading the bundled Chef version
Setting up development environment
Check setting up development environment docs for instructions on setting up a environment for local development.
Understanding the architecture
Check the architecture documentation for an full description of the various components of this project, and how they work together.
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 (eg. security issue, 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
Merge Request Guidelines
If you are working on a new feature or an issue which doesn’t have an entry on Omnibus GitLab’s 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
- Changelog entry to inform about the change, if necessary.
Note: Ensure shared runners are enabled for your fork in order for our automated tests to run:
- Go to Settings -> CI/CD
- Expand Runners settings
- If shared runners are not enabled, click on the button labeled “Enable shared Runners”
Validating changes to a single software dependency
It can be useful to only build one piece of software, rather than rebuild the whole package each time. For instance, when adding a new software definition. Using this method, you can quickly rebuild an omnibus package containing only the software and its dependencies. Once you’ve confirmed the software builds on its own, you can add it to the Omnibus GitLab build and confirm it there. To use this:
- Setup your development environment
Copy the simple.rb file into your projects
cp doc/development/examples/simple.rb config/projects/
- Change the
config/projects/simple.rbto match the software you are testing
Build the simple project by running
bundle exec omnibus build simple
Testing changes during install/upgrade
If you are working on changes to the install/upgrade process, and not the reconfigure process itself, you can use the scripts/repack-deb tool to quickly repack an existing GitLab deb with changes from your local branch. It will repack the existing deb file into a new deb containing the local content from