-
Notifications
You must be signed in to change notification settings - Fork 90
Add docker and don't push build #27
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
base: openMaxIO-main
Are you sure you want to change the base?
Conversation
Update README.md
|
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@lateststill 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) |
|
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. |
|
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. |
## 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.
Addresses: #4, #5, #8, #13
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.