Skip to content

Latest commit

 

History

History
203 lines (145 loc) · 7.39 KB

CONTRIBUTING.md

File metadata and controls

203 lines (145 loc) · 7.39 KB
Raw

Contributors Guide

Bug Reports

Please open an issue and use the provided template to include all necessary details.

The more detailed your report, the faster it can be resolved and will ensure it is resolved in the right way. Once your bug has been resolved, the responsible person will tag the issue as Needs confirmation and assign the issue back to you. Once you have tested and confirmed that the issue is resolved, close the issue. If you are not a member of the project, you will be asked for confirmation and we will close it.

Documentation

If you would like to help with documentation, please note that for most cases the Wiki has been deprecated in favor of markdown files placed in a new /doc subdirectory of the repository itself. Please submit a pull request with your changes/additions based off the the stable branch.

The documentation is rendered on haskellstack.org by readthedocs.org using Sphinx and CommonMark. Since links and formatting vary from GFM, please check the documentation there before submitting a PR to fix those.

If your changes move or rename files, or subsume Wiki content, please continue to leave a file/page in the old location temporarily, in addition to the new location. This will allow users time to update any shared links to the old location. Please also update any links in other files, or on the Wiki, to point to the new file location.

Code

If you would like to contribute code to fix a bug, add a new feature, or otherwise improve stack, pull requests are most welcome. It's a good idea to submit an issue to discuss the change before plowing into writing code.

If you'd like to help out but aren't sure what to work on, look for issues with the awaiting pull request label. Issues that are suitable for newcomers to the codebase have the newcomer friendly label. Best to post a comment to the issue before you start work, in case anyone has already started.

Please include a ChangeLog entry and documentation updates with your pull request.

Code Quality

The Stack projects uses HLint as a code quality tool.

Note that stack contributors need not dogmatically follow the suggested hints but are encouraged to debate their usefulness. If you find a hint is not useful and detracts from readability, consider marking it in the configuration file to be ignored. Please refer to the HLint manual for configuration syntax.

Quoting @mgsloan:

We are optimizing for code clarity, not code concision or what HLint thinks.

You can install HLint with stack. You might want to install it in the global project in case you run into dependency conflicts. HLint can report hints in your favourite text editor. Refer to the HLint repository for more details.

To install:

stack install hlint

Once installed, you can check your changes with:

$ ./etc/scripts/hlint.sh

Testing

The Stack code has both unit tests and integration tests. Integration tests can be found in the test/integration folder and unit tests, in the src/test folder. Tests are written using the Hspec framework. In order to run the full test suite, you can simply do:

$ stack test

The --file-watch is a very useful option to get quick feedback. However, running the entire test suite after each file change will slow you down. You'll need to specify which test suite (unit test or integration) and pass arguments to specify which module you'd specifically like to run to get quick feedback. A description of this follows below.

Working with Unit Tests

If you would like to run the unit tests on their own, you can:

$ stack test stack:stack-test

Running an individual module works like this:

$ stack test stack:stack-test --ta "-m <PATTERN>"

Where <PATTERN> is the name of the module without Spec.hs.

You may also load tests into GHCi and run them with:

$ stack ghci stack:stack-test --only-main
# GHCi starting up output ...
> :main -m "<PATTERN>"

Where again, <PATTERN> is the name of the module without Spec.hs.

Working with Integration Tests

Running the integration tests is a little involved, you'll need to:

$ stack build --flag stack:integration-tests stack --interleaved-output --exec stack-integration-test

Running an individual module works like this:

$ stack build --flag stack:integration-tests stack --interleaved-output --exec "stack-integration-test -m <PATTERN>"

Where <PATTERN> is the name of the folder listed in the test/integration/tests/ folder.

You may also achieve this through GHCi with:

$ stack ghci stack:stack-integration-test
# GHCi starting up output ...
> :main -m "<PATTERN>"

Where again, <PATTERN> is the name of the folder listed in the test/integration/tests/ folder.

CI Build rules

We use Azure to do CI builds on Stack. There are two types of build which happens there:

Test suite build

This builds the code with --pedantic, performs hlint checks and it runs all test suites on multiple GHC/OS configuration. These are the rules for triggering it:

  • CI will run this if commits are pushed to stable, master branch
  • CI will run this for any branches starting with ci/
  • CI will run this for all new PR's.

Integration based build

This build runs the integration tests in the Stack codebase. This is scheduled to run daily once for both the stable and master branches.

Also, you can manually run this on a specific branch from the Azure UI if you have the appropriate permissions. If you'd specifically like a branch or PR to run integration tests, add a comment in the PR and we can queue one up.

Skipping build

There are times (like a minor type fix) where you don't want the CI to run. For those cases, you can add [skip ci] or [ci skip] in your commit message to skip the builds. For more details, refer here.

Slack channel

If you're making deep changes and real-time communcation with the Stack team would be helpful, we have a #stack-collaborators Slack channel. Please contact @borsboom (manny@fpcomplete.com) or @snoyberg (michael@fpcomplete.com) for an invite.