Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Deprecate public coder/modules repo #532

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
f0ssel opened this issue Mar 26, 2025 · 6 comments
Open

Deprecate public coder/modules repo #532

f0ssel opened this issue Mar 26, 2025 · 6 comments
Assignees

Comments

@f0ssel
Copy link

f0ssel commented Mar 26, 2025

This issue hinges on #531 being completed.

Once all modules have been migrated to the central Hub repo, we'll need to officially deprecate the coder/modules repo. Not fully sure about everything that would go into that, but this also seems like an issue that would be more for Product.

@f0ssel f0ssel added this to the Registry Profiles milestone Mar 26, 2025
@Parkreiner Parkreiner changed the title Deprecate old modules repo Deprecate modules repo Mar 27, 2025
@Parkreiner Parkreiner changed the title Deprecate modules repo Deprecate coder/modules repo Mar 27, 2025
@Parkreiner Parkreiner changed the title Deprecate coder/modules repo Deprecate public coder/modules repo Mar 27, 2025
Parkreiner added a commit to coder/registry that referenced this issue Apr 17, 2025
Addresses part of coder/internal#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.
@Parkreiner
Copy link
Member

Parkreiner commented Apr 21, 2025

Most of work needed to flag the modules repo as deprecated is done now, but the last piece is making sure we migrate all the Bash scripts and CI processes (some are already, but not all). Probably going to spend Tuesday working on that, and then use Wednesday/Thursday to start on the Registry site updates

@Parkreiner
Copy link
Member

Parkreiner commented Apr 22, 2025

Making a quick checklist of work that still needs to be done before we can consider deprecating the modules repo:

All items with linked PRs should hopefully be done once those PRs are merged in

@Parkreiner
Copy link
Member

@matifali Do you have the bandwidth to be able to help out with updating the new.sh and release.sh Bash scripts?

@matifali
Copy link
Member

matifali commented Apr 23, 2025

@Parkreiner, Yes, I can look into them next week. If there are any issues, please assign them to me. I am also willing to pair on these so that we all know how it works.

Parkreiner added a commit to coder/registry that referenced this issue Apr 29, 2025
More work towards closing coder/internal#532

## Changes made
- Added Bash script to run `terraform validate` on all relevant repos
- Updated `package.json` and CI to use the script
@Parkreiner
Copy link
Member

Going to be closing out this issue in favor of making smaller-scoped issues

@Parkreiner
Copy link
Member

Actually, maybe not a great idea, since we still want to make sure we don't forget the actual migration process

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants