5 Commits

Author SHA1 Message Date
DevCats
a47ff911e1
fix: Version-Bump Workflow/Script - Formatting before diff (#155)
## 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>
2025-06-19 16:35:10 -05:00
blink-so[bot]
f5bf6687e7
feat: extract version bump logic into reusable script (#140)
# 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>
2025-06-10 21:17:39 -05:00
Michael Smith
9e18a4e3a8
chore: add prettier/typo check to CI (#14)
## 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
2025-04-29 10:09:22 -04:00
Michael Smith
494a25e688 fix: make site health check eaiser to use 2025-04-22 14:35:20 +00:00
Michael Smith
376664ca04
chore: migrate all Coder modules to Registry repo (#4)
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.
2025-04-17 09:49:54 -04:00