House IntelliJ Gazelle as part of bazel-contrib

[blorente]

IntelliJ Gazelle is an IntelliJ plugin that allows users to run Gazelle when they sync a project with the regular Bazel Plugin, ensuring that projects that rely on it are always operating with up to date BUILD files. The code can be found here: https://github.com/blorente/intellij_gazelle

As previously discussed in the open source #rules channel, I believe that bazel-contrib would be a good place to host its development, and perhaps its eventual publication int o the JetBrains Marketplace.

For installation, usage and debug instructions, please refer to the README at the root of the repository. There is also an explanation of why this functionality isn't included in the standard Bazel Plugin.

---

To do list:

• [x] Include Apache 2 licence file
• [x] Add CODEOWNERS file
• [ ] Set up CI with tests and release infrastructure

[alexeagle]

This is blocked on https://github.com/bazel-contrib/SIG-rules-authors/issues/3 but I think that issue can be resolved simply by encoding our existing thoughts into a doc on our site.

[alexeagle]

3 is resolved now - could you just look at https://bazel-contrib.github.io/SIG-rules-authors/hosting-policy.html#adding-criteria and demonstrate that all those criteria are met?

[illicitonion]

I believe @blorente is unreachable for a bit, but on his behalf (I've edited the original issue description with a TODO list):

Must use an open-source license, preferably Apache-2.0.

We're happy to release as Apache 2.

Must have wide applicability in the community.

Gazelle and IntelliJ are broadly used in the community - most Go projects use Gazelle, and IntelliJ is commonplace. This plugin helps with the overlap.

Must have a clear point of contact who answers questions from the SIG.

@blorente is this point of contact; I'm happy to act as a backup.

Must be “production quality”: clear README or other documentation outlining the goal of these rules, how to use them etc.

I think the README is reasonable :)

generated API documentation

n/a - project doesn't have an API (and isn't rules).

include examples of use

README contains screenshots of configuration.

tests that are running continuously

Not yet!

Must reply to issues/PRs in 2-3 weeks (exact service level agreement TBD)

Happy to sign up to do so, but hard to provide evidence in advance!

Must have more than one person who is committed to review/approve PRs

@blorente + @illicitonion > 1

We recommend encoding this as a CODEOWNERS file.

TODO

Must publish semver releases.

Publishing needs to be wired up. Because this isn't an API, and lives in the IntelliJ plugin ecosystem, I'm not sure semver actually makes sense here, but open to discussion.

Optional: follow the same release pattern as the rules-template does.

n/a - not a ruleset.

Must work with LTS Bazel version

It does!

[gibfahn]

@blorente is this point of contact; I'm happy to act as a backup. Must have more than one person who is committed to review/approve PRs

For what it's worth if we need further "official" points of contact we can provide them (although I suspect Borja and Daniel will be enough from a responsiveness Point of View, and the rest of the team will keep an eye on the repo too).

tests that are running continuously

In general this seems like a good goal to have, but one to set up after the initial project move. Maybe some of these should be marked "should be done in the first 30 days after adding the project" or something.

[alexeagle]

Thanks! The SIG has discretion about whether the missed criteria are essential or not. I don't see why adding some automated testing after transferring the repository is any easier than doing it beforehand, but I also imagine that won't be a blocker, especially as you all have community reputation already :) Will review it next SIG meeting.

[blorente]

Thanks everyone for weighing in! Added a LICENSE and CODEOWNERS file. As per the third requirement, we are still finding the time to implement it, but here is the sketch of the testing infrastructure:

Testing

We will write IntelliJ headless tests, which are integration tests run on headless editors. The only functionality of the plugin is "Does the correct gazelle target run", so a handful of test repositories with before/after states should be enough.

CI

The CI setup should be pretty simple, as long as we get a hold of a Docker image with:

• Bazel -> To run Gazelle.
• Gradle -> To run the tests.

CD

Bundling and publishing is done by Gradle, in a manually-triggered CI job. There is a bundled task (publishPlugin) to publish to the official repositories.

For versioning, I propose we follow senver, but appending versions with the IntelliJ API version: v<pluginVer>-api<IntelliJVer> (e.g. v0.1-api213). Different versions of the IntelliJ API may need different versions of the plugin, hence the appending. This is how the Bazel Plugin operates: e.g. 2022.04.20.0.2-api-version-213. They prepend dates to their versions, but I don't think this plugin will change enough to warrant that.

Open Questions

[ ] What org and signature would we publish this under?

[blorente]

This work has now been upstreamed to https://github.com/bazelbuild/intellij, so closing this issue.