mirror of
https://github.com/renovatebot/renovate.git
synced 2025-01-12 06:56:24 +00:00
110 lines
5.3 KiB
Markdown
110 lines
5.3 KiB
Markdown
# Local Development
|
|
|
|
This document serves to give tips and tricks on how to run Renovate locally to add features or fix bugs.
|
|
Please submit PRs to improve it if you think anything is unclear or you can think of something that should be added.
|
|
|
|
## Install
|
|
|
|
#### Fork and Clone
|
|
|
|
If you will contribute to the project, you should first "fork" it using the GitHub Website and then clone your fork.
|
|
|
|
#### Node version
|
|
|
|
Renovate supports node.js versions 8 and above. Use a version manager like `nvm` or `n` if you'll need to switch between versions easily.
|
|
|
|
#### Install dependencies
|
|
|
|
We use [yarn](https://github.com/yarnpkg/yarn) so run `yarn install` to install dependencies instead of `npm install`.
|
|
|
|
#### Verify installation
|
|
|
|
Run `yarn start`. You should see this error:
|
|
|
|
```
|
|
FATAL: Renovate fatal error: You need to supply a GitHub token.
|
|
```
|
|
|
|
## Platform Account Setup
|
|
|
|
Although it's possible to make small source code improvements without testing against a real repository, in most cases it's important that you run a "real" test on a repository before you submit a feature or fix. It's possible to do this against GitHub or GitLab public hosts, and you can also use both.
|
|
|
|
#### Register new account (optional)
|
|
|
|
It's recommended that you set up a dedicated test account on GitHub or GitLab, so that you minimise the risk that you accidentally cause problems when testing out Renovate.
|
|
|
|
e.g. if your GitHub username is "alex88" then maybe you register "alex88-testing" for use with Renovate.
|
|
|
|
#### Generate platform token
|
|
|
|
Once you have decided on your platform and account, log in and generate a "Personal Access Token" that can be used to authenticate Renovate.
|
|
|
|
#### Export platform token
|
|
|
|
Although you can specify a token to Renovate using `--token=`, it is annoying if you need to include this every time.
|
|
You are better off to instead export an Environment Variable for this.
|
|
|
|
If your platform of choice is GitHub, then export `GITHUB_TOKEN`, and if it's GitLab then export `GITLAB_TOKEN`.
|
|
It's also find to export both so that you can switch between platforms.
|
|
|
|
## Tests
|
|
|
|
You can run `yarn test` locally to test your code. We test all PRs using the same tests, run on TravisCI. `yarn test` runs an `eslint` check, a `prettier` check, and then all the unit tests using `jest`.
|
|
|
|
## Jest
|
|
|
|
You can run just the Jest unit tests by running `yarn jest`. You can also run just a subset of the Jest tests using file matching, e.g. `yarn jest lock-files` or `yarn jest workers/branch`. If you get a test failure due to a "snapshot" mismatch, and you are sure that you need to update the snapshot, then you can append `-u` to the end. e.g. `yarn jest lock-files -u` would update the saved Snapshots for _all_ tests in `test/workers/branch/lock-files.spec.js`.
|
|
|
|
#### Coverage
|
|
|
|
The Renovate project maintains 100% test coverage, so any Pull Request will fail if it does not contain full coverage for code.
|
|
Using `// istanbul ignore` is not ideal but sometimes is a pragmatic solution if an additional test wouldn't really prove anything.
|
|
|
|
To view the current test coverage locally, open up `coverage/lcov-report/index.html` in your browser.
|
|
|
|
Do not let coverage put you off submitting a PR! Maybe we can help, or at least guide.
|
|
Also, it can be good to submit your PR as a work in progress (WIP) without tests first so that you can get a thumbs up from others about the changes, and write tests after.
|
|
|
|
#### Linting and formatting
|
|
|
|
We use [Prettier](https://github.com/prettier/prettier) for code formatting. If your code fails `yarn test` due to a `prettier` rule then you should find that the offending file will be updated automatically and pass the second time you run `yarn test` because each time you run it, it includes the `--fix` command automatically. You usually shouldn't need to fix any prettier errors manually.
|
|
|
|
## Tips and tricks
|
|
|
|
#### Forked repositories
|
|
|
|
Quite often, the quickest way for you to test or fix something is to fork an existing repository.
|
|
However, by default Renovate skips over repositories that are forked.
|
|
To override this default, you need to specify the setting `renovateFork` as `true`.
|
|
|
|
Option 1: Add `"renovateFork": true` to the `renovate.json` of the repository
|
|
Option 2: Run Renovate with the CLI flag `--renovate-fork=true`
|
|
|
|
#### Log files
|
|
|
|
Usually, `debug` is good enough to troubleshoot most problems or verify functionality.
|
|
|
|
When logging at debug, it's usually easiest to view the logs in a text editor, so in that case you can run like this:
|
|
|
|
```
|
|
$ rm -f debug.log && yarn start myaccount/therepo --log-level=debug > debug.log
|
|
```
|
|
|
|
The above will delete any existing `debug.log` and then save Renovate's output to that file.
|
|
|
|
#### Adding configuration options
|
|
|
|
We wish to keep backwards-compatibility as often as possible, as well as make
|
|
the code configurable, so most new functionality should be controllable via
|
|
configuration options.
|
|
|
|
If you wish to add one, add it to `lib/config/definitions.js` and then add documentation to `website/docs/_posts/2017-10-05-configuration-options.md`.
|
|
|
|
## Debugging
|
|
|
|
It's really easy to debug Renovate using Chrome's inspect tool. Try like this:
|
|
|
|
1. Open `chrome://inspect` in Chrome, then click on "Open dedicated DevTools for Node"
|
|
2. Run `yarn debug ...` instead of `yarn start ...`
|
|
3. Add a `debugger;` statement somewhere in the source code where you want to start debugging
|
|
4. Click "Resume script execution" in Chrome DevTools and wait for your break point to be triggered
|