## Description
Makes the version extract and replace logic more specific so it wont
replace any field that does is not specifically `field` under the
detected modules.
<!-- Briefly describe what this PR does and why -->
## Type of Change
- [ ] New module
- [ ] New template
- [X] Bug fix
- [ ] Feature/enhancement
- [ ] Documentation
- [ ] Other
## Testing & Validation
- [X] Tests pass (`bun test`)
- [X] Code formatted (`bun fmt`)
- [X] Changes tested locally
## Related Issues
#510
<!-- Link related issues or write "None" if not applicable -->
---------
Co-authored-by: Atif Ali <atif@coder.com>
## Description
Set up Pre-Req's, and ensure that formatting is done before checking
diff since it likes to not respect prettier formatting.
---
## Type of Change
- [ ] New module
- [X] Bug fix
- [ ] Feature/enhancement
- [ ] Documentation
- [ ] Other
---
## Testing & Validation
- [X] Tests pass (`bun test`)
- [X] Code formatted (`bun run fmt`)
- [ ] Changes tested locally
---------
Co-authored-by: Atif Ali <atif@coder.com>
# 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 made
- Added back CI steps for validating the codebase for typos and formatting
- Updated README validation CI step to be dependent on typo-checking step
- Updated configuration files as needed to support the new CI step
- Updated all files that were previously getting skipped over from improperly-set-up CI logic
Addresses part of https://github.com/coder/internal/issues/532 (but doesn't fully close it out).
This is a huge PR, but chunking it up seemed pointless, since we're largely copying over existing files. I'm going to try commenting on the main areas I think are worth paying attention to
## Changes made
- Migrated over all Coder modules from coder/modules, and put them in their correct user namespaces.
- Added README.md files to all newly-created user namespaces
- Updated all image paths for every image used, to make sure they don't break (I switched the paths programmatically, and then manually verified every README to guarantee this).
- Added README.md files for each contributor who previously made a module
- Updated our `tsconfig.json` file to use modern libraries when run from the server, and made a custom `tsconfig.json` just for the `windows-rdp` module (which has more restrictive browser concerns)
- Added CI step to run all the module tests we currently have
## Notes
- There were a lot of Bash script files that weren't carried over in this PR, partly because I don't know Bash well enough to know (1) whether they're still needed, or (2) modify them to account for the new file structure. Those can be brought over later.
- We had a `lint.ts` file that provided some light validation of some of the modules. After going through it, there were so many bugs and issues with the code that I legitimately think that it barely provided a safety net at all. I got rid of it entirely, with the intention of adding the functionality that was originally intended to the current validation logic (to be handled in a separate PR).
- I changed how we set up the `.images` directory, because it felt like it would be chaos if a bunch of users try to throw all their images in one giant directory, with no guidelines on how to do it. I instead made it so that images should be scoped by namespace, which felt a lot more manageable. The `.icons` directory is still at the top level, because realistically, there are only going to be so many types of icons referenced, so it's fine for those to be shared.
- I don't think the `maintainer_github` and `contributor_github` fields make sense anymore, but those can be stripped out once we've updated the Registry site build step to use the new Registry repo
- My gut instinct is to use the user namespace to determine the main owner of the module, and then add a `contributors` string list to indicate which other users have contributed meaningfully to it. We can then add validation to make sure that every value in that list exists as another namespace in the repo
## What still needs to be migrated (in separate PRs)
These are the main files of interest that still probably need to be copied over from the `/modules` repo:
- `new.sh`
- `terraform_validate.sh`
- `update-version.sh`
They're probably going to require enough changes that it's worth handling them in a separate PR.
DevCats