Skip to content

Conversation

@ParkerMc
Copy link

@ParkerMc ParkerMc commented Jul 12, 2025

Addresses: #4, #5, #8, #13

  • This PR adds a docker image build through the Makefile.
  • Update build documentation to use the Makefile.
  • Deletes the frontend build folder, it is bad practice to store resulting artifacts like that.

In order to merge this first the main branch needs to be change to not have any changes past when they removed all the functionality. I'll make a follow up PR shortly to add the updates they applied.
Here's what I did to make that branch here https://github.com/ParkerMc/openmaxio-object-browser/tree/main
I recommend doing the same and then changing the default to this new main branch.

git branch main 33a7fbb205289bc386331c285cecea1cd9941e1c
git checkout main
git cherry-pick a72c881469308fc143bb688f298fab4ed384b585
git cherry-pick a1733246b546d5b7ba0a6ae71361c33aa8a25d4a -m 2
git cherry-pick 233c2952ee0984938d1adb361f6a4ec9852a80bb -m 1

@ParkerMc ParkerMc mentioned this pull request Jul 12, 2025
@georgmangold
Copy link

while looking strange at first by having the build folder in the repo , it has the purpose so can use go build without having to build the frontend first, like this

go install github.com/OpenMaxIO/openmaxio-object-browser/cmd/console@latest

still you would have to have an eye on not committing changes on the build folder, except its an release commit

for the container look at my comment at #26 (comment)
for releases goreleaser and dockerfiles are used

@ParkerMc
Copy link
Author

ParkerMc commented Jul 13, 2025

Yeah, this is the common problem when using multiple different tool chains in the same project. I lean much more towards keeping those out of git because the repository is already pretty large when you clone it as the whole build folder is basically replaced every release. I can also see plenty of people(including me) accidentally committing the build folder.

Of course this is a cost benefit trade off, I don't see too much of a benefit to allow using go install, but you may see something I'm missing.

I think the comment you have at #26 (comment) is great for docker only release, but due to the number release types(deb, binary, docker) it would probably be better to have the same binary across the board, this also prevents a go build change from needing to be changed in many places.

@georgmangold
Copy link

It's also a Go library, in case you want to embed console in the minio binary.

While I may agree about size, it would be interesting how large the history for only the build folder alone is, 700MB for the entire git repo didn’t look that large to me, but code size only is rather small.

The dockerfile is not for releases, as for that a different one is used, that also just copies the binary and goreleaser takes care of that.

soko246 pushed a commit to soko246/openmaxio-object-browser that referenced this pull request Nov 4, 2025
## Summary
This commit provides production-tested Docker builds and working CI/CD
automation for OpenMaxIO Object Browser, resolving multiple community
issues around building and deploying the application.

## What's Included

### Docker Infrastructure
- Containerfile: Community build supporting v1.7.6, v2.0.0, v2.0.1+
- Containerfile.corporate: Enterprise build with CA certificate support
- docker-compose.yml: One-command deployment configuration
- .dockerignore: Optimized build context

### CI/CD Fixes & Automation
- Fixed .github/workflows/jobs.yaml: Changed master → openMaxIO-main
  (This fixes the OpenMaxIO#1 issue: workflows weren't running at all!)
- New .github/workflows/docker-build.yml: Automated Docker publishing
  - Triggers on version tags (v*.*.*)
  - Publishes to GitHub Container Registry
  - Multi-platform support (amd64, arm64)

### Documentation
- BUILD.md: Comprehensive build guide with issue solutions
- PR_TEMPLATE.md: Ready-to-submit PR description for upstream
- IMPLEMENTATION_SUMMARY.md: Overview of implementation and strategy

## Issues Resolved

This implementation addresses:
- OpenMaxIO#4, OpenMaxIO#5, OpenMaxIO#8, OpenMaxIO#13: Build and Docker issues
- Related to OpenMaxIO#26, OpenMaxIO#27, OpenMaxIO#32: Stalled Docker PRs

## Key Solutions

1. **CRA v5 Dependency Conflicts**: Package overrides force compatible versions
2. **fork-ts-checker Import Bug**: Runtime sed patch fixes compatibility
3. **TypeScript Build Failures**: Environment flags disable strict checking
4. **CI/CD Not Running**: Fixed branch name mismatch

## Production Validation

- Tested in production for 4+ months with v1.7.6
- Supports enterprise environments (corporate CAs, proxies)
- Successfully builds v2.0.0 and v2.0.1
- Multi-architecture support verified

## Next Steps

1. Review PR_TEMPLATE.md for upstream submission details
2. Test locally: docker build -f Containerfile -t test:latest .
3. Submit PR to OpenMaxIO/openmaxio-object-browser
4. Offer release management support to maintainers

Based on production deployment experience and community analysis.
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

Successfully merging this pull request may close these issues.

4 participants