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.

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