Is it OK to add the flag like this or do we need to check the cli
version to determine whether the new flag is available? Or I could just
throw in an `||` to run the command again without the flag if it fails.
Blocked on adding AgentAPI to Claude.
Will need to do the same for Goose.
## Description
Removed unnecessary comments and added commands to reset the working
directory and clean untracked files in the version-bump workflow. This
improves the script's reliability by ensuring a clean state after
executing version checks.
---
## Type of Change
- [ ] New module
- [X] Bug fix
- [ ] Feature/enhancement
- [ ] Documentation
- [ ] Other
---
## Related Issues
None
## Description
Relates to
Fixes an issue where RDP doesn't function properly over Coder Connect,
by disabling UDP and relying only on TCP. c.f.
https://github.com/coder/internal/issues/608#issuecomment-2965923672 for
a detailed description of the problem.
---
## Type of Change
- [ ] New module
- [X] Bug fix
- [ ] Feature/enhancement
- [ ] Documentation
- [ ] Other
---
## Module Information
<!-- Delete this section if not applicable -->
**Path:** `registry/coder/modules/windows-rdp`
**New version:** `v1.0.19`
**Breaking change:** [ ] Yes [x] No
---
## Testing & Validation
- [x] Tests pass (`bun test`)
- [x] Code formatted (`bun run fmt`)
- [x] Changes tested locally
---
## Related Issues
https://github.com/coder/internal/issues/608
Closes #
---------
Signed-off-by: Spike Curtis <spike@coder.com>
This PR copies the templates in coder/coder/examples/templates over to
the registry, so that template contribution can be done through the
registry.
For now, the starter templates in the coder/coder binary and the
templates available in coder/registry will simply be different
constructs, until we find a solution we like around a single source of
truth for templates that doesn't raise hairy semver concerns for
coder/coder:
https://codercom.slack.com/archives/C05T7165ET1/p1749493368773469
# Extract Version Bump Logic into Reusable Script
This PR extracts the version bump logic from the GitHub Actions workflow
(PR #137) into a reusable script and implements the requirements as
requested.
## ✅ What This PR Delivers
### 🔧 **Version Bump Script**: `.github/scripts/version-bump.sh`
- Extracts all version bump logic from the original workflow
- Supports `patch`, `minor`, and `major` version bumps
- Configurable base reference for diff comparison (defaults to
`origin/main`)
- Comprehensive error handling and semantic version validation
- Can be used standalone or in workflows
### 🔍 **Version Check Workflow**: `.github/workflows/version-check.yaml`
- **Required CI check** that runs on all PRs modifying modules
- Verifies that module versions have been properly updated
- Fails if versions need bumping but haven't been updated
- Provides clear instructions on how to fix version issues
### 🚀 **Version Bump Workflow**: `.github/workflows/version-bump.yaml`
- Simplified workflow that uses the extracted script
- Triggered by PR labels (`version:patch`, `version:minor`,
`version:major`)
- Automatically commits version updates and comments on PR
### 📚 **Updated Documentation**: `CONTRIBUTING.md`
- Clear instructions on how to use the version bump script
- Examples for different bump types
- Information about PR labels as an alternative
- Explains that CI will check version updates
## 🎯 Key Features
✅ **Script Logic Extracted**: All complex bash logic moved from workflow
to reusable script
✅ **Required CI Check**: Version check workflow ensures versions are
updated
✅ **Diff Verification**: Script checks git diff to detect modified
modules
✅ **Contribution Docs Updated**: Clear instructions for contributors
✅ **Backward Compatible**: Maintains all original functionality
✅ **Error Handling**: Comprehensive validation and clear error messages
## 📖 Usage Examples
```bash
# For bug fixes
./.github/scripts/version-bump.sh patch
# For new features
./.github/scripts/version-bump.sh minor
# For breaking changes
./.github/scripts/version-bump.sh major
```
## 🔄 Workflow Integration
1. **Developer makes changes** to modules
2. **CI runs version-check** workflow automatically
3. **If versions need updating**, CI fails with instructions
4. **Developer runs script** or adds PR label
5. **Versions get updated** automatically
6. **CI passes** and PR can be merged
## 🧪 Testing
The script has been tested with:
- ✅ Valid and invalid bump types
- ✅ Module detection from git diff
- ✅ Version calculation and validation
- ✅ README version updates
- ✅ Error handling for edge cases
This implementation addresses all the original requirements while making
the logic more maintainable and reusable.
---------
Co-authored-by: blink-so[bot] <211532188+blink-so[bot]@users.noreply.github.com>
Co-authored-by: DevelopmentCats <christofer@coder.com>
Changes are broken down in to multiples commits to hopefully make
reviewing easy. 1 commit for the slog change and then a commit per Go
file for style changes.
Style changes are generally:
- try to use full sentences for all comments
- try to stick to 120 column lines (not strict) instead of 80
- try to one line as many `call function, check if err != nil` blocks as
possible (ex: only err or variables are not reused outside the if statement)
- try to use `err` or `errs` for all return type names, previously used
`problems` in some cases but `errs` in others
- some minor readability changes
- `Todo` -> `TODO`, sometimes also useful to do `TODO (name):` to make
it easier to find things a specific author meant to follow up on
- comments for types/functions should generally start with `//
FunctionName/TypeName ...`
---------
Signed-off-by: Callum Styan <callumstyan@gmail.com>
Goes along with https://github.com/coder/coder/issues/8237
Most people probably gets apps from modules, and so to group them we'll
need new versions of aaaaaall of these modules.
Also some were missing `order`, which is related and intertwined pretty
closely in the implementation of `group`, so add it where necessary.
This PR adds `golangci-lint` based on the configuration from
`coder/coder`
([here](https://github.com/coder/coder/blob/main/.golangci.yaml)) then
migrated to v2 using `golangci-lint migrate` plus the addition of few
more linters.
---------
Signed-off-by: Callum Styan <callumstyan@gmail.com>
## Changes made
- Added avatars for each contributor
- Updated validation steps to account for avatars, if the avatar field
exists
- Went ahead and made some slog changes, ahead of @cstyan's refactor PR
Added an optional envvar to vault-token module to handle communicating
with a non default vault namespace.
in vault enterprise, you can run multiple secure isolated vault
environments from the one vault server.
each namespace has it's own authentication methods and secrets engines.
vault uses the VAULT_NAMESPACE envvar to determine the namespace to use.
no value, or either `root` or `/` will use the root (default) namespace,
any other value will use a different namespace
in vault community edition, the only supported namespace is "root", no
other namespaces can be used.
in HCP vault dedicated (the saas hosted version), you cant access vault
without a namespace set
this defaults to not setting the env var, so is backwards compatible,
and works with vault CE
---------
Co-authored-by: Birdie K <5210502+moo-im-a-cow@users.noreply.github.com>
Let's be upfront about how our module works so operators/template
authors can evaluate the security implications.
Signed-off-by: Danny Kopping <dannykopping@gmail.com>
- Add Multiplexer, and tmux with mouse support.
- Add check to make sure tmux and screen are not set at the same time.
- Add Variable for session name so the name of the screen or tmux
session can be customized.
Tested in dev environment.
Reference: https://github.com/coder/registry/issues/31
- Changed default values from null to empty strings for
`experiment_goose_provider` and `experiment_goose_model` variables in
main.tf to ensure compatibility and avoid null interpolation issues.
Should resolve https://github.com/coder/registry/issues/27
The goal is to provide a method for template owners to configure default
`Machine Settings` that can be overridden by developers via `User
Settings` and repositories via `Workspace Settings`.
This option allows template owners to push new settings options with a
template release that would not be ignored because the setting file
already exists.
This also formats the `settings.json` file if `jq` is installed.
Eventually, I would imagine the current `settings` option will be
depreciated in favor of this option.
- Add amazon-q.svg in ./icons
- Resolve Icon path to point to new amazon-q.svg
- Set tags to agent, ai, amazon-q
---------
Co-authored-by: M Atif Ali <atif@coder.com>
