2020-10-30 14:08:56 -04:00
---
stage: none
group: unassigned
2020-11-26 01:09:20 -05:00
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
2020-10-30 14:08:56 -04:00
---
2014-04-24 13:53:18 -04:00
# Rake tasks for developers
2020-04-21 11:21:10 -04:00
Rake tasks are available for developers and others contributing to GitLab.
2014-04-24 13:53:18 -04:00
2020-04-21 11:21:10 -04:00
## Set up database with developer seeds
Note that if your database user does not have advanced privileges, you must create the database manually before running this command.
2014-04-24 13:53:18 -04:00
2020-02-07 22:08:47 -05:00
```shell
2014-04-24 13:53:18 -04:00
bundle exec rake setup
```
2018-01-19 05:09:59 -05:00
The `setup` task is an alias for `gitlab:setup` .
2019-08-12 06:29:10 -04:00
This tasks calls `db:reset` to create the database, and calls `db:seed_fu` to seed the database.
2020-11-03 19:09:12 -05:00
`db:setup` calls `db:seed` but this does nothing.
2014-12-04 10:54:08 -05:00
2020-04-21 11:21:10 -04:00
### Environment variables
2019-11-15 07:06:12 -05:00
**MASS_INSERT**: Create millions of users (2m), projects (5m) and its
relations. It's highly recommended to run the seed with it to catch slow queries
while developing. Expect the process to take up to 20 extra minutes.
2020-04-21 11:21:10 -04:00
See also [Mass inserting Rails models ](mass_insert.md ).
**LARGE_PROJECTS**: Create large projects (through import) from a predefined set of URLs.
2019-11-15 07:06:12 -05:00
2019-04-17 06:23:06 -04:00
### Seeding issues for all or a given project
You can seed issues for all or a given project with the `gitlab:seed:issues`
task:
```shell
# All projects
bin/rake gitlab:seed:issues
# A specific project
bin/rake "gitlab:seed:issues[group-path/project-path]"
```
By default, this seeds an average of 2 issues per week for the last 5 weeks per
project.
2019-07-08 04:50:38 -04:00
#### Seeding issues for Insights charts **(ULTIMATE)**
2019-05-05 09:57:21 -04:00
You can seed issues specifically for working with the
2019-05-19 19:27:22 -04:00
[Insights charts ](../user/group/insights/index.md ) with the
2019-05-05 09:57:21 -04:00
`gitlab:seed:insights:issues` task:
```shell
# All projects
bin/rake gitlab:seed:insights:issues
# A specific project
bin/rake "gitlab:seed:insights:issues[group-path/project-path]"
```
By default, this seeds an average of 10 issues per week for the last 52 weeks
2020-11-25 22:09:17 -05:00
per project. All issues are also randomly labeled with team, type, severity,
2019-05-05 09:57:21 -04:00
and priority.
2021-02-16 19:09:19 -05:00
#### Seeding groups with subgroups
2020-01-30 07:08:54 -05:00
2021-02-16 19:09:19 -05:00
You can seed groups with subgroups that contain milestones/projects/issues
2020-01-30 07:08:54 -05:00
with the `gitlab:seed:group_seed` task:
```shell
bin/rake "gitlab:seed:group_seed[subgroup_depth, username]"
```
Group are additionally seeded with epics if GitLab instance has epics feature available.
2020-04-08 23:09:28 -04:00
#### Seeding custom metrics for the monitoring dashboard
A lot of different types of metrics are supported in the monitoring dashboard.
To import these metrics, you can run:
```shell
bundle exec rake 'gitlab:seed:development_metrics[your_project_id]'
```
2017-07-13 11:43:57 -04:00
### Automation
If you're very sure that you want to **wipe the current database** and refill
2020-12-21 07:10:22 -05:00
seeds, you can set the `FORCE` environment variable to `yes` :
2017-07-13 11:43:57 -04:00
2020-02-07 22:08:47 -05:00
```shell
2020-12-21 07:10:22 -05:00
FORCE=yes bundle exec rake setup
2017-07-13 11:43:57 -04:00
```
2020-12-21 07:10:22 -05:00
This will skip the action confirmation/safety check, saving you from answering
`yes` manually.
2017-07-13 11:43:57 -04:00
2020-04-21 11:21:10 -04:00
### Discard `stdout`
2017-07-13 11:43:57 -04:00
Since the script would print a lot of information, it could be slowing down
your terminal, and it would generate more than 20G logs if you just redirect
it to a file. If we don't care about the output, we could just redirect it to
`/dev/null` :
2020-02-07 22:08:47 -05:00
```shell
2017-07-13 11:43:57 -04:00
echo 'yes' | bundle exec rake setup > /dev/null
```
2020-04-21 11:21:10 -04:00
Note that since you can't see the questions from `stdout` , you might just want
to `echo 'yes'` to keep it running. It would still print the errors on `stderr`
2017-07-13 11:43:57 -04:00
so no worries about missing errors.
2019-01-07 16:05:35 -05:00
### Extra Project seed options
There are a few environment flags you can pass to change how projects are seeded
- `SIZE` : defaults to `8` , max: `32` . Amount of projects to create.
2020-11-25 22:09:17 -05:00
- `LARGE_PROJECTS` : defaults to false. If set, clones 6 large projects to help with testing.
- `FORK` : defaults to false. If set to `true` , forks `torvalds/linux` five times. Can also be set to an existing project `full_path` to fork that instead.
2019-01-07 16:05:35 -05:00
2014-04-24 13:53:18 -04:00
## Run tests
2016-08-05 11:19:37 -04:00
In order to run the test you can use the following commands:
2019-02-22 08:17:10 -05:00
2020-04-21 11:21:10 -04:00
- `bin/rake spec` to run the RSpec suite
2019-12-12 01:07:42 -05:00
- `bin/rake spec:unit` to run only the unit tests
- `bin/rake spec:integration` to run only the integration tests
- `bin/rake spec:system` to run only the system tests
2019-11-27 01:06:40 -05:00
- `bin/rake karma` to run the Karma test suite
2014-04-24 13:53:18 -04:00
2020-04-21 11:21:10 -04:00
`bin/rake spec` takes significant time to pass.
Instead of running the full test suite locally, you can save a lot of time by running
a single test or directory related to your changes. After you submit a merge request,
2020-11-25 22:09:17 -05:00
CI runs full test suite for you. Green CI status in the merge request means
2017-02-06 20:42:39 -05:00
full test suite is passed.
2016-08-05 11:19:37 -04:00
2020-11-25 22:09:17 -05:00
You can't run `rspec .` since this tries to run all the `_spec.rb`
2016-08-05 11:19:37 -04:00
files it can find, also the ones in `/tmp`
2020-04-21 11:21:10 -04:00
You can pass RSpec command line options to the `spec:unit` ,
`spec:integration` , and `spec:system` tasks. For example, `bin/rake "spec:unit[--tag ~geo --dry-run]"` .
2019-05-22 08:16:49 -04:00
2020-04-21 11:21:10 -04:00
For an RSpec test, to run a single test file you can run:
2016-08-05 11:19:37 -04:00
2020-04-21 11:21:10 -04:00
```shell
bin/rspec spec/controllers/commit_controller_spec.rb
```
2016-08-05 11:19:37 -04:00
To run several tests inside one directory:
2020-04-21 11:21:10 -04:00
- `bin/rspec spec/requests/api/` for the RSpec tests if you want to test API only
2016-08-05 11:19:37 -04:00
2020-04-21 11:21:10 -04:00
### Speed up tests, Rake tasks, and migrations
2017-05-03 06:09:47 -04:00
2020-06-11 17:08:37 -04:00
[Spring ](https://github.com/rails/spring ) is a Rails application pre-loader. It
2017-05-03 06:09:47 -04:00
speeds up development by keeping your application running in the background so
2020-03-31 08:08:09 -04:00
you don't need to boot it every time you run a test, Rake task or migration.
2017-05-03 06:09:47 -04:00
2020-11-25 22:09:17 -05:00
If you want to use it, you must export the `ENABLE_SPRING` environment
2017-05-03 06:09:47 -04:00
variable to `1` :
2020-02-07 22:08:47 -05:00
```shell
2017-05-03 06:09:47 -04:00
export ENABLE_SPRING=1
```
2014-04-24 13:53:18 -04:00
2018-03-01 18:48:49 -05:00
Alternatively you can use the following on each spec run,
2020-02-07 22:08:47 -05:00
```shell
2018-03-01 18:48:49 -05:00
bundle exec spring rspec some_spec.rb
```
2017-03-22 15:30:54 -04:00
## Compile Frontend Assets
You shouldn't ever need to compile frontend assets manually in development, but
if you ever need to test how the assets get compiled in a production
environment you can do so with the following command:
2020-02-07 22:08:47 -05:00
```shell
2017-03-22 15:30:54 -04:00
RAILS_ENV=production NODE_ENV=production bundle exec rake gitlab:assets:compile
```
2020-11-25 22:09:17 -05:00
This compiles and minifies all JavaScript and CSS assets and copy them along
2017-03-22 15:30:54 -04:00
with all other frontend assets (images, fonts, etc) into `/public/assets` where
they can be easily inspected.
2020-04-21 11:21:10 -04:00
## Emoji tasks
2017-11-14 16:32:45 -05:00
2020-04-21 11:21:10 -04:00
To update the Emoji aliases file (used for Emoji autocomplete), run the
2017-11-14 16:32:45 -05:00
following:
2020-02-07 22:08:47 -05:00
```shell
2017-11-14 16:32:45 -05:00
bundle exec rake gemojione:aliases
```
2020-04-21 11:21:10 -04:00
To update the Emoji digests file (used for Emoji autocomplete), run the
2016-06-23 09:30:35 -04:00
following:
2020-02-07 22:08:47 -05:00
```shell
2016-06-23 09:30:35 -04:00
bundle exec rake gemojione:digests
```
2020-11-25 22:09:17 -05:00
This updates the file `fixtures/emojis/digests.json` based on the currently
2016-06-23 09:30:35 -04:00
available Emoji.
2020-04-21 11:21:10 -04:00
To generate a sprite file containing all the Emoji, run:
2016-06-23 09:30:35 -04:00
2020-02-07 22:08:47 -05:00
```shell
2016-06-23 09:30:35 -04:00
bundle exec rake gemojione:sprite
```
2016-07-13 10:43:42 -04:00
2020-06-11 17:08:37 -04:00
If new emoji are added, the sprite sheet may change size. To compensate for
such changes, first generate the `emoji.png` sprite sheet with the above Rake
task, then check the dimensions of the new sprite sheet and update the
2016-07-13 10:43:42 -04:00
`SPRITESHEET_WIDTH` and `SPRITESHEET_HEIGHT` constants accordingly.
2017-08-07 08:21:28 -04:00
2020-04-21 11:21:10 -04:00
## Update project templates
2017-08-07 08:21:28 -04:00
Starting a project from a template needs this project to be exported. On a
2019-12-12 01:07:42 -05:00
up to date master branch run:
2017-08-07 08:21:28 -04:00
2020-02-07 22:08:47 -05:00
```shell
2019-12-12 01:07:42 -05:00
gdk start
2017-08-07 08:21:28 -04:00
bundle exec rake gitlab:update_project_templates
git checkout -b update-project-templates
git add vendor/project_templates
git commit
git push -u origin update-project-templates
```
Now create a merge request and merge that to master.
2018-06-06 04:19:12 -04:00
## Generate route lists
To see the full list of API routes, you can run:
```shell
bundle exec rake grape:path_helpers
```
2020-06-24 20:09:26 -04:00
The generated list includes a full list of API endpoints and functional
RESTful API verbs.
2018-06-06 04:19:12 -04:00
For the Rails controllers, run:
```shell
bundle exec rake routes
```
Since these take some time to create, it's often helpful to save the output to
a file for quick reference.
2019-09-11 12:23:42 -04:00
## Show obsolete `ignored_columns`
To see a list of all obsolete `ignored_columns` run:
2020-02-07 22:08:47 -05:00
```shell
2019-09-11 12:23:42 -04:00
bundle exec rake db:obsolete_ignored_columns
```
Feel free to remove their definitions from their `ignored_columns` definitions.
2019-10-15 20:06:16 -04:00
2021-02-08 13:09:49 -05:00
## Validate GraphQL queries
To check the validity of one or more of our front-end GraphQL queries,
run:
```shell
# Validate all queries
bundle exec rake gitlab::graphql:validate
# Validate one query
bundle exec rake gitlab::graphql:validate[path/to/query.graphql]
# Validate a directory
bundle exec rake gitlab::graphql:validate[path/to/queries]
```
This prints out a report with an entry for each query, explaining why
each query is invalid if it fails to pass validation.
We strip out `@client` fields during validation so it is important to mark
client fields with the `@client` directive to avoid false positives.
## Analyze GraphQL queries
Analogous to `ANALYZE` in SQL, we can run `gitlab:graphql:analyze` to
estimate the of the cost of running a query.
Usage:
```shell
# Analyze all queries
bundle exec rake gitlab::graphql:analyze
# Analyze one query
bundle exec rake gitlab::graphql:analyze[path/to/query.graphql]
# Analyze a directory
bundle exec rake gitlab::graphql:analyze[path/to/queries]
```
This prints out a report for each query, including the complexity
of the query if it is valid.
The complexity depends on the arguments in some cases, so the reported
complexity is a best-effort assessment of the upper bound.
2020-04-21 11:21:10 -04:00
## Update GraphQL documentation and schema definitions
2019-10-15 20:06:16 -04:00
To generate GraphQL documentation based on the GitLab schema, run:
```shell
bundle exec rake gitlab:graphql:compile_docs
```
2020-03-31 08:08:09 -04:00
In its current state, the Rake task:
2019-10-15 20:06:16 -04:00
- Generates output for GraphQL objects.
2019-10-16 20:07:27 -04:00
- Places the output at `doc/api/graphql/reference/index.md` .
2019-10-15 20:06:16 -04:00
This uses some features from `graphql-docs` gem like its schema parser and helper methods.
The docs generator code comes from our side giving us more flexibility, like using Haml templates and generating Markdown files.
2020-12-07 04:09:42 -05:00
To edit the content, you may need to edit the following:
- The template. You can edit the template at `lib/gitlab/graphql/docs/templates/default.md.haml` .
The actual renderer is at `Gitlab::Graphql::Docs::Renderer` .
- The applicable `description` field in the code, which
[Updates machine-readable schema files ](#update-machine-readable-schema-files ),
which is then used by the `rake` task described earlier.
2019-10-15 20:06:16 -04:00
`@parsed_schema` is an instance variable that the `graphql-docs` gem expects to have available.
2019-10-16 20:07:27 -04:00
`Gitlab::Graphql::Docs::Helper` defines the `object` method we currently use. This is also where you
should implement any new methods for new types you'd like to display.
2019-10-31 23:06:26 -04:00
### Update machine-readable schema files
To generate GraphQL schema files based on the GitLab schema, run:
```shell
bundle exec rake gitlab:graphql:schema:dump
```
2020-04-08 02:09:54 -04:00
This uses GraphQL Ruby's built-in Rake tasks to generate files in both [IDL ](https://www.prisma.io/blog/graphql-sdl-schema-definition-language-6755bcb9ce51 ) and JSON formats.
2021-02-23 07:10:56 -05:00
### Update documentation and schema definitions
The following command combines the intent of [Update GraphQL documentation and schema definitions ](#update-graphql-documentation-and-schema-definitions ) and [Update machine-readable schema files ](#update-machine-readable-schema-files ):