Repository files navigation

Coder Gateway connects your JetBrains IDE toCoder workspaces so that you can develop from anywhere.

Manage less

• Ensure your entire team is using the same tools and resources
  • Rollout critical updates to your developers with one command
• Automatically shut down expensive cloud resources
• Keep your source code and data behind your firewall

Code more

• Build and test faster
  • Leveraging cloud CPUs, RAM, network speeds, etc.
• Access your environment from any place on any client (even an iPad)
• Onboard instantly then stay up to date continuously

Install this plugin from the JetBrains Marketplace

To manually install a local build:

1. InstallJetbrains Gateway
2. run./gradlew clean buildPlugin to generate a zip distribution
3. locate the zip file in thebuild/distributions folder and followthese instructions on how to install a plugin from disk.

Alternatively,./gradlew clean runIde will deploy a Gateway distribution (the one specified ingradle.properties -platformVersion) with the latest plugin changes deployed.

To simulate opening a workspace from the dashboard pass the Gateway link via--args. For example:

./gradlew clean runIDE --args="jetbrains-gateway://connect#type=coder&workspace=dev&agent=coder&folder=/home/coder&url=https://dev.coder.com&token=<redacted>&ide_product_code=IU&ide_build_number=223.8836.41&ide_download_link=https://download.jetbrains.com/idea/ideaIU-2022.3.3.tar.gz"

Alternatively, if you have separately built the plugin and already installed itin a Gateway distribution you can launch that distribution with the URL as thefirst argument (no--args in this case).

├── .github/                GitHub Actions workflows and Dependabot configuration files├── gradle│   └── wrapper/            Gradle Wrapper├── build/                  Output build directory├── src                     Plugin sources│   └── main│       ├── kotlin/         Kotlin production sources│       └── resources/      Resources - plugin.xml, icons, i8n│   └── test│       ├── kotlin/         Kotlin test sources├── .gitignore              Git ignoring rules├── build.gradle.kts        Gradle configuration├── CHANGELOG.md            Full change history├── gradle.properties       Gradle configuration properties├── gradlew                 *nix Gradle Wrapper script├── gradlew.bat             Windows Gradle Wrapper script├── qodana.yml              Qodana profile configuration file├── README.md               README└── settings.gradle.kts     Gradle project settings

src directory is the most important part of the project, the Coder Gateway implementation and the manifest for the plugin –plugin.xml.

The project-specific configuration filegradle.properties contains:

The properties listed define the plugin itself or configure thegradle-intellij-plugin – check its documentation for more details.

Run tests with./gradlew test. By default this will test againsthttps://dev.coder.com but you can setCODER_GATEWAY_TEST_DEPLOYMENT to a URLof your choice or tomock to use mocks only.

Code quality is monitored with the help ofQodana

Qodana inspections are accessible within the project on two levels:

• using theQodana IntelliJ GitHub Action, run automatically within theBuild workflow,
• with theGradle Qodana Plugin, so you can use it on the local environment or any CI other than GitHub Actions.

Qodana inspection is configured with theqodana { ... } section in theGradle build file andqodana.yml YAML configuration file.

NOTE: Qodana requires Docker to be installed and available in your environment.

To run inspections, you can use a predefinedRun Qodana configuration, which will provide a full report onhttp://localhost:8080, or invoke the Gradle task directly with the./gradlew runInspections command.

A final report is available in the./build/reports/inspections/ directory.

./gradlew runPluginVerifier can check the plugin compatibility against the specified Gateway. The integration with Github Actions is commented untilthis gradle intellij plugin issue is fixed.

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

• Build
  • Triggered onpush andpull_request events.
  • Runs theGradle Wrapper Validation Action to verify the wrapper's checksum.
  • Runs theverifyPlugin andtest Gradle tasks.
  • Builds the plugin with thebuildPlugin Gradle task and provides the artifact for the next jobs in the workflow.
  • Verifies the plugin using theIntelliJ Plugin Verifier tool. (this is commented untilthis issue is fixed)
  • Prepares a draft release of the GitHub Releases page for manual verification.
• Release
  • Triggered onPublish release event.
  • UpdatesCHANGELOG.md file with the content provided with the release note.
  • Publishes the plugin to JetBrains Marketplace using the providedPUBLISH_TOKEN.
  • Sets publish channel depending on the plugin version, i.e.1.0.0-beta ->beta channel. For now, bothmainandeap branches are published on default release channel.
  • Patches the Changelog and commits.

When themain oreap branch receives a new pull request or a direct push, theBuild workflow runs builds the 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, the current plugin version, for example,v2.1.0.The changelog is provided automatically using thegradle-changelog-plugin.An artifact file is also built with the plugin attached. Every new Build overrides the previous draft to keep theReleases page clean.

When you edit the draft and use thePublish release button, GitHub will tag the repository with the given version and add a new entry to the Releases tab.Next, it will notify users who arewatching the repository, triggering the finalRelease workflow.

IMPORTANT:pluginVersion fromgradle.properties needs to be manually increased after a release.

Plugin Signing is a mechanism introduced in the 2021.2 release cycle to increase security inJetBrains Marketplace.

JetBrains Marketplace signing is designed to ensure that plugins are not modified over the course of the publishing and delivery pipeline.

The plugin signing configuration is disabled for coder-gateway. To find out how to generate signing certificates and how to configure the signing task,check thePlugin Signing section in the IntelliJ Platform Plugin SDK documentation.

gradle-intellij-plugin provides thepublishPlugin Gradle task to upload the plugin artifacts. TheRelease workflowautomates this process by running the task when a new release appears in the GitHub Releases section.

Note

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 thebetarelease channel.

The authorization process relies on thePUBLISH_TOKEN secret environment variable, specified in theSecrets section of the repositorySettings.

You can get that token in your JetBrains Marketplace profile dashboard in theMy Tokens tab.

When releasing an update, it is essential to let 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:

• theCHANGELOG.md file,
• theReleases page,
• theWhat's new section of JetBrains Marketplace Plugin page,
• and inside the Plugin Manager's item details.

Coder Gateway follows theKeep a Changelog approach for handling the project's changelog.

TheGradle Changelog Plugin takes care of propagating information provided within theCHANGELOG.md to theGradle IntelliJ Plugin.You only have to take care of writing down the actual changes in proper sections of the[Unreleased] section.

You start with an almost empty changelog:

# YourPlugin Changelog## [Unreleased]### Added- Initial scaffold created from [IntelliJ Platform Plugin Template](https://github.com/JetBrains/intellij-platform-plugin-template)

Now proceed with providing more entries to theAdded group, or any other one that suits your change the most (seeHow do I make a good changelog? for more details).

When releasing a plugin update, you don't have to care about bumping the[Unreleased] header to the upcoming version – it will be handled automatically on the Continuous Integration (CI) after you publish your plugin.GitHub Actions will swap it and provide you an empty section for the next release so that you can proceed with the development:

# YourPlugin Changelog## [Unreleased]## [0.0.1]### Added- An awesome feature### Fixed- One annoying bug

Gateway API has not reached maturity. More often than not, there are API incompatibilities betweenthe latest stable version of Gateway and EAP ones (Early Access Program). To provide support for bothversions of Gateway we've decided:

• to have two branches for releases:main andeap
• main branch will provide support for the latest stable Gateway release, whileeap will providesupport for releases in the EAP program.
• both versions of the plugin will keep the MAJOR.MINOR.PATCH numbers in sync. When there is a fixin the plugin's business code, these versions will change and the changes on themain branch willhave to be merged on theeap branch as well.
• releases fromeap branch are suffixed with-eap.x.x will allow releases for the same pluginfunctionality but with support for a different Gateway EAP version. In other words, version2.1.2of the plugin supports Gateway 2022.2 while version2.1.2-eap.0 supports some builds in the Gateway2022.3 EAP.2.1.2-eap.1 might have to support a newer version of EAP.
• when Gateway 2022.3 EAP is released in the stable channel theneap branch will have to be merged backin themain branch, and it will start supporting the next EAP builds.
• releases from both branches are published in the stable release channel. Jetbrains provides support fordifferent release channels (ex:eap orbeta), but all of them except the stable channel have to bemanually configured by users in Gateway - which is super inconvenient.

Coder Gateway includes checks for compatibility with a specified version range. A warning is raised whenthe Coder deployment build version is outside of compatibility range:

The range needs to be manually updated as often as possible. The lowest bound is specified byminCompatibleCoderVersionproperty in theCoderSupportedVersions.propertieswhilemaxCompatibleCoderVersion specifies the upper bound.