## Summary Fixes #72 - The `jfrog-oauth` module now fails with a clear error message when the JFrog access token is empty, instead of silently creating configurations with empty tokens. ## Changes ### 1. Added Precondition Validation (`main.tf`) ```hcl lifecycle { precondition { condition = data.coder_external_auth.jfrog.access_token != "" error_message = "JFrog access token is empty. Please authenticate with JFrog using external auth." } } ``` This ensures the module fails at **plan time** with a clear error when users haven't authenticated via external auth. ### 2. Replaced `main.test.ts` with `jfrog-oauth.tftest.hcl` **Why we removed the TypeScript tests:** The TypeScript tests used `runTerraformApply()` which runs `terraform apply` directly. This approach **cannot mock data sources** like `coder_external_auth`. The Coder provider returns empty strings for tokens by default when running outside a real Coder workspace. With our new precondition, the TypeScript tests would always fail because: 1. `terraform apply` runs → empty `access_token` from mock provider 2. Precondition check fails → "JFrog access token is empty" 3. Test fails before any assertions run **The solution:** Terraform's native `.tftest.hcl` format supports `override_data` blocks that can properly mock data sources: ```hcl override_data { target = data.coder_external_auth.jfrog values = { access_token = "valid-token-value" # or "" to test failure } } ``` ### 3. Comprehensive Test Coverage The new `jfrog-oauth.tftest.hcl` includes **12 tests** (up from 7): | Test | What it validates | |------|------------------| | `test_required_vars` | Basic module works with required variables | | `test_empty_access_token_fails` | **NEW:** Precondition rejects empty tokens | | `test_valid_access_token_succeeds` | Module works with valid token | | `test_jfrog_url_validation` | **NEW:** URL must start with http(s):// | | `test_username_field_validation` | **NEW:** Must be "email" or "username" | | `test_with_npm_package_manager` | NPM config with scoped repos (script content) | | `test_configure_code_server` | **NEW:** IDE env vars created when enabled | | `test_go_proxy_env` | GOPROXY env value with multiple repos | | `test_pypi_package_manager` | pip.conf with extra-index-url | | `test_docker_package_manager` | register_docker commands for all repos | | `test_conda_package_manager` | .condarc channels configuration | | `test_maven_package_manager` | settings.xml with servers and repos | All package manager tests use `strcontains()` to verify the actual script content matches expected configuration formats. ## Test Limitations (Acknowledged) The tests verify **template rendering** but not **runtime execution**: | ✅ What we test | ❌ What we don't test | |----------------|----------------------| | Configuration file formats | Script syntax errors at runtime | | Variable interpolation | JFrog CLI compatibility | | Precondition validation | Actual JFrog authentication | | Script contains expected content | Commands execute successfully | **Rationale:** The original TypeScript tests also only checked script content (`toContain()`), not execution. Full execution testing would require a mock JFrog server, which adds significant complexity for limited benefit. The script is straightforward bash that configures files and runs CLI commands. ## Testing ```bash cd registry/coder/modules/jfrog-oauth terraform test # Success! 12 passed, 0 failed. ``` _Generated with [mux](https://github.com/coder/mux)_
Coder Registry
Registry Site • Coder OSS • Coder Docs • Official Discord
Coder Registry is a community-driven platform for extending your Coder workspaces. Publish reusable Terraform as Coder Modules for users all over the world.
Note
The Coder Registry repo will be updated to support Coder Templates in the coming weeks. You can currently find all official templates in the official coder/coder repo, under the
examples/templatesdirectory.
Overview
Coder is built on HashiCorp's open-source Terraform language to provide developers an easy, declarative way to define the infrastructure for their remote development environments. Coder-flavored versions of Terraform allow you to mix in reusable Terraform snippets to add integrations with other popular development tools, such as JetBrains, Cursor, or Visual Studio Code.
Simply add the correct import snippet, along with any data dependencies, and your workspace can start using the new functionality immediately.
More information about Coder Modules can be found here, while more information about Coder Templates can be found here.
Getting started
The easiest way to discover new modules and templates is by visiting the official Coder Registry website. The website is a full mirror of the Coder Registry repo, and it is where .tar versions of the various resources can be downloaded from, for use within your Coder deployment.
Note that while Coder has a baseline set of requirements for allowing an external PR to be published, Coder cannot vouch for the validity or functionality of a resource until that resource has been flagged with the verified status. All modules under the Coder namespace are automatically verified.
Getting started with modules
To get started with a module, navigate to that module's page in either the registry site, or the main repo:
In both cases, the main README contains a Terraform snippet for integrating the module into your workspace. The snippet for Cursor looks like this:
module "cursor" {
count = data.coder_workspace.me.start_count
source = "registry.coder.com/coder/cursor/coder"
version = "1.0.19"
agent_id = coder_agent.main.id
}
Simply include that snippet inside your Coder template, defining any data dependencies referenced, and the next time you create a new workspace, the functionality will be ready for you to use.
Contributing
We are always accepting new contributions. Please see our contributing guide for more information.
For Maintainers
Guidelines for maintainers reviewing PRs and managing releases. See the maintainer guide for more information.
