With this plugin you can run your java code with environment variables from .env file in project root. Repository https://github.com/cm-kazup0n/IDEA-Envfile

1. Build plugin package with buildPlugin task.
2. Built package will be generated in ./build/distributions/.
3. Then install plugin from disk.

NOTE: This plugin is not published in plugin repository.

> ./gradlew buildPlugin
> ls build/distributions/
IdeaEnvFile-X.X.X.zip

If there's an .env file in project root. The plugin automatically load its contents into environment variable when program runs.

Within the default project structure, there is a .run directory provided containing three predefined Run/Debug configurations that expose corresponding Gradle tasks:

TIP: You can find the logs from the running task in the idea.log tab.

Continuous integration depends on GitHub Actions, a set of workflows that make it possible to automate your testing and release process. Thanks to such automation, you can delegate the testing and verification phases to the CI and instead focus on development (and writing more tests).

In the .github/workflows directory, you can find definitions for the following GitHub Actions workflows:

• Build
  • Triggered on push and pull_request events.
  • Runs the Gradle Wrapper Validation Action to verify the wrapper's checksum.
  • Runs the verifyPlugin and test Gradle tasks.
  • Builds the plugin with the buildPlugin Gradle task and provides the artifact for the next jobs in the workflow.
  • Verifies the plugin using the IntelliJ Plugin Verifier tool.
  • Prepares a draft release of the GitHub Releases page for manual verification.
• Release
  • Triggered on released event.
  • Publishes the plugin to the Marketplace using the provided PUBLISH_TOKEN.
  • Sets publish channel depending on the plugin version, i.e. 1.0.0-beta -> beta channel.
  • Patches the Changelog and commits.

All the workflow files have accurate documentation, so it's a good idea to take a look through their sources.

This project depends on Gradle plugins and external libraries – and during the development, you will add more of them. Keeping the project in good shape and having all the dependencies up-to-date requires time and effort, but it is possible to automate that process using dependabot. Dependabot is a bot provided by GitHub for checking the build configuration files and reviewing any outdated or insecure dependencies of yours – in case if any update is available, it creates a new pull request providing the proper change.

Note: Dependabot doesn't yet support checking of the Gradle Wrapper. Check the Gradle Releases page and update it with:

./gradlew wrapper --gradle-version 6.8

When releasing an update, it is important to let your users know what the new version offers. The best way to do this is to provide release notes.

The changelog is a curated list that contains information about any new features, fixes, and deprecations. When they are provided, these lists are available in a few different places: the CHANGELOG.md file, the Releases page, the What's new section of the Marketplace Plugin page, and inside of the Plugin Manager's item details.

There are many methods for handling the project's changelog. The one used in the current template project is the Keep a Changelog approach.

The release process depends on the workflows already described above. When your main branch receives a new pull request or a regular push, the Build workflow runs multiple tests on your plugin and prepares a draft release.

The draft release is a working copy of a release, which you can review before publishing. It includes a predefined title and git tag, which is the current version of the plugin, for example, v0.0.1. The changelog is provided automatically using the gradle-changelog-plugin. An artifact file is also built with the plugin attached. Every new Build overrides the previous draft to keep your Releases page clean.

When you edit the draft and use the Publish release button, GitHub will tag your repository with the given version and add a new entry to the Releases tab. Next, it will notify users that are watching the repository, and it will trigger the final Release workflow.

Releasing a plugin to the Marketplace is a straightforward operation that uses the publishPlugin Gradle task provided by the gradle-intellij-plugin. The Release workflow automates this process by running the task when a new release appears in the GitHub Releases section.

TIP: Set a suffix to the plugin version to publish it in the custom repository channel, i.e. v1.0.0-beta will push your plugin to the beta release channel.

The authorization process relies on the PUBLISH_TOKEN secret environment variable, which has to be acquired through the Secrets section of the repository Settings.

You can get that token in the My Tokens tab within your Marketplace profile dashboard.

Important: Before using the automated deployment process, it is necessary to manually create a new plugin in the Marketplace to specify options like the license, repository URL, etc. Please follow the Publishing a Plugin instructions.

Java language is supported by default along with Kotlin. Initially, there's /src/main/kotlin directory available with some minimal examples. You can still replace it or add next to it the /src/main/java to start working with Java language instead.

Since the February 2021, GitHub Actions support the skip CI feature. If the message contains one of the following strings: [skip ci], [ci skip], [no ci], [skip actions], or [actions skip] – workflows will not be triggered.

• IntelliJ Platform SDK DevGuide
• IntelliJ Platform Explorer
• Marketplace Quality Guidelines
• IntelliJ Platform UI Guidelines
• Marketplace Paid Plugins
• Kotlin UI DSL
• IntelliJ SDK Code Samples
• JetBrains Platform Slack
• JetBrains Platform Twitter
• IntelliJ IDEA Open API and Plugin Development Forum
• Keep a Changelog
• GitHub Actions