|
| 1 | +# Contributing to clojurephant-tooling |
| 2 | + |
| 3 | +## Asking a question or getting help |
| 4 | + |
| 5 | +The following is the preferred communication channel: |
| 6 | + |
| 7 | +- Start a discussion in [Clojurephant Discussions](https://github.com/clojurephant/clojurephant/discussions) |
| 8 | + |
| 9 | +The following are not actively monitored: |
| 10 | + |
| 11 | +- Start a topic in [ClojureVerse Projects/gradle-clojure](https://clojureverse.org/c/projects/gradle-clojure) |
| 12 | +- Ask in [Clojurians Slack #gradle](http://clojurians.net/) |
| 13 | + |
| 14 | +## Submitting a bug report or feature request |
| 15 | + |
| 16 | +Create a new issue and fill out the template. Thanks for providing feedback on what's important to you as a user! |
| 17 | + |
| 18 | +## Roadmap |
| 19 | + |
| 20 | +See the [milestones](https://github.com/clojurephant/clojurephant-tooling/milestones) for details on planned features. |
| 21 | + |
| 22 | +## Contributing documentation or code |
| 23 | + |
| 24 | +Pull requests are very welcome. Thanks in advance for helping the project (that goes double for those of you updating documentation)! |
| 25 | + |
| 26 | +- **For minor changes:** Go right ahead and submit a PR. |
| 27 | +- **For already open issues:** Comment in the issue that you'd like to help out on to ensure it's not already being worked on and to get guidance from the team. |
| 28 | +- **For new features:** Open an issue first detailing the feature. This will let the team provide feedback on how that feature can work best for the project. |
| 29 | + |
| 30 | +### Development Setup |
| 31 | + |
| 32 | +- Clone this repo. |
| 33 | +- Have a Java 8 or higher JDK installed. |
| 34 | +- If using Eclipse or Intellij: |
| 35 | + - Import the project as a Gradle project. |
| 36 | + - Import the Eclipse formatter preferences from `.gradle/eclipse-java-formatter.xml`. (See _Code Style_ for more information.) |
| 37 | + |
| 38 | +### Project Structure |
| 39 | + |
| 40 | +- Documentation is under `docs/`. |
| 41 | + - If you add a new page, make sure to add it to the following locations so that it's in the nav: |
| 42 | + - `docs/_includes/nav.md` (for the https://clojurephant.dev site) |
| 43 | + - `docs/cljdoc.edn` (for the https://cljdoc.org docs) |
| 44 | +- Modules: |
| 45 | + - Plugin itself is in `clojurephant-plugin/` |
| 46 | +- Test suite: |
| 47 | + - Functional Gradle tests (run against a range of Gradle versions) are in `clojurephant-plugin/src/compatTest` |
| 48 | +- Sample Projects: |
| 49 | + - These are separate repositories under the Clojurephant organization |
| 50 | + |
| 51 | +### Gradle Resources |
| 52 | + |
| 53 | +A few helpful resources if you're new to writing Gradle plugins: |
| 54 | + |
| 55 | +- [Gradle User Manual](https://docs.gradle.org/current/userguide/userguide.html), specifically: |
| 56 | + - [Designing Gradle plugins](https://guides.gradle.org/designing-gradle-plugins/) (see bottom of guide for links to further guides) |
| 57 | + - [Lazy task configuration](https://docs.gradle.org/current/userguide/lazy_configuration.html) |
| 58 | +- [Gradle DSL Reference](https://docs.gradle.org/current/dsl/) |
| 59 | + |
| 60 | +### Testing Sample Projects |
| 61 | + |
| 62 | +1. Clone the sample repo |
| 63 | +1. Use the project like normal to test its functionality |
| 64 | + |
| 65 | +### Code Style |
| 66 | + |
| 67 | +This project uses the [Google Java Style Guide](https://google.github.io/styleguide/javaguide.html). Google provides [google-java-format](https://github.com/google/google-java-format) and an [Eclipse formatter profile](https://github.com/google/styleguide/blob/gh-pages/eclipse-java-google-style.xml) to help automate this. Both however have a weakness in how they line wrap, primarily for code that heavily uses lambdas. The style guide's text allows for more discretion in where line wrapping happens, but the automated ones can be overzealous. For this reason, we are using a modified version of the Eclipse profile that disables the automatic line wrapping. |
| 68 | + |
| 69 | +The style is enforced using the [spotless](https://github.com/diffplug/spotless) plugin, which can also reformat your code to comply with the style with `./gradlew spotlessApply`. |
| 70 | + |
| 71 | +You can import the Eclipse formatter settings `.gradle/eclipse-java-formatter.xml` to have your IDE respect the style. |
| 72 | + |
| 73 | +## Maintainer/Collaborator Processes |
| 74 | + |
| 75 | +### CI Configuration |
| 76 | + |
| 77 | +clojurephant is built on GitHub Actions. This is configured in `.github/workflows/*.yaml`. |
| 78 | + |
| 79 | +There are two workflows: |
| 80 | + |
| 81 | +- `ci` - General build verification running on all branches and PRs on push: |
| 82 | + - Runs full `./gradlew check` and `./gradlew compatTest` test suites and style verification. |
| 83 | + - Runs on all supported Java versions (currently 8, 11, 17). |
| 84 | +- `release` - Publishing the plugin to Gradle's Plugin Portal and Clojars |
| 85 | + - When a tag is pushed, it will do a release/publish (i.e. _don't make a tag unless you're trying to release_). |
| 86 | + |
| 87 | +### Updating our dependencies |
| 88 | + |
| 89 | +To update the lock with the latest versions matching any ranges we specified: |
| 90 | + |
| 91 | +``` |
| 92 | +./gradlew lock --write-locks |
| 93 | +``` |
| 94 | + |
| 95 | +### Supporting new Gradle versions |
| 96 | + |
| 97 | +The following task will update our lock files will the latest available versions that match the compatibility rules in our `stutter {}` block in `clojurephant-plugin/build.gradle`. |
| 98 | + |
| 99 | +``` |
| 100 | +./gradlew stutterWriteLocks |
| 101 | +``` |
| 102 | + |
| 103 | +The `stutter {}` block can also be used to change the ranges we support. See [stutter's documentation](https://github.com/ajoberstar/gradle-stutter) for details. |
| 104 | + |
| 105 | +### Release Process |
| 106 | + |
| 107 | +We use [reckon](https://github.com/ajoberstar/reckon) to manage our versioning and tagging. There is no version number stored in the build file, reckon will determine this automatically from the project history and user input. |
| 108 | + |
| 109 | +We have 3 release stages: |
| 110 | + |
| 111 | +- `beta` - significant functionality that we'd like to release but the version isn't feature-complete yet |
| 112 | +- `rc` - intended as a `final` release, but want to provide an opportunity for bug testing |
| 113 | +- `final` - no known or significant bugs were found in the rc, and it's ready for general consumption |
| 114 | + |
| 115 | +To generate a release: |
| 116 | + |
| 117 | +- (For `rc` or `final`) Make sure all issues in [GitHub milestone](https://github.com/clojurephant/clojurephant/milestones). |
| 118 | +- (For `final`) make sure we've released an `rc` already for this commit. |
| 119 | +- Have the `master` branch checked out |
| 120 | +- Run `./gradlew reckonTagPush -Preckon.stage=<stage>` (e.g. `./gradlew reckonTagPush -Preckon.stage=beta`) |
| 121 | + - This will run `check` on the project, create a version tag, and push that tag |
| 122 | + - The tag push will trigger GitHub Actions to run the `release` workflow, including the publish step if tests pass on all supported Java versions. |
| 123 | + - The publish will push the plugin to Clojars, and the Gradle Plugin Portal. |
| 124 | +- Go to the GitHub [releases](https://github.com/clojurephant/clojurephant/releases) and draft a new release. Use [the template](https://raw.githubusercontent.com/clojurephant/clojurephant/master/.github/RELEASE_TEMPLATE.md) for consistency. Ensure you check the _is a pre-release_ if this is a `beta` or `rc`. |
0 commit comments