Skip to content
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

Build multi-arch images on AWS spot instances #157

Closed
wants to merge 7 commits into from

Conversation

pyldin601
Copy link
Contributor

No description provided.

@pyldin601 pyldin601 closed this Feb 8, 2022
@wader
Copy link
Owner

wader commented Feb 8, 2022

As this is quite generic one idea could be to have this as a separate repo that is reusable by other builds? other repos could trigger it to build by using https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_dispatch for example? just thinking out loud 🤔

Btw do you have any idea roughly what a spot instance static-ffmpeg build costs? good to have clue what kind of money it is :)

@pyldin601
Copy link
Contributor Author

@wader It costed to me around $0.07 to build the arm64 image yesterday.

@mathieu-aubin
Copy link
Contributor

maybe, just maybe, could different arches be set on different --blank-- ?

insert branch, repo, project or whatever here.

I think, maybe i think, that a universal solution complicates things to a point where it discourages MANY from participating to the project, as in... "well i had thjs thing working but cant have it aprooved only if i can invest time into something i could careless, moving on to other shit!"

I hope you understand my idea here and that i have proven to be of help mor3 than a nuisance here which, altho irrelevant in the discussion, could give some weight to such (my) statement in the realm of at least being entertained and a shit be attributed. Geee i love when i get brain farts like theses.

Thanks and as many my exes said, keep it up!

@mathieu-aubin
Copy link
Contributor

Re-reading...

another --blank-- would allow for more seamless resolution of disparitions between advancements with regards to feasability and issues pertaining to having over complicated hacks that are, well, worth whatever to whomever (irrelavant) and for which opinions greatly vary. It could cause impediments into the whole with regards to advancements and block even the tiniest relevant and positive 'milestone' or better said, achievement of progress

@wader
Copy link
Owner

wader commented Feb 8, 2022

@mathieu-aubin No worries and i much appreciative your contributions, ideas and attitude! I think i understand what you mean and i too really wish to keep things as simple as possible and that the Dockerfile should be usable with just a docker build .. I think most of headaches we have seen has been because docker:s leaky emulation, if it was native hosts i think things would just-work much more.

But i guess it's a bit of a balance, having just one multi-arch image would be quite neat also and very clean and simple for users of the image. So in summary for me i think it's a good idea be allow hacky things inside the Dockerfile to do whatever is needed to produce static binaries but be cautious with complicated things in CI and build env etc?

Thanks and as many my exes said, keep it up!

Same! 😁

@wader
Copy link
Owner

wader commented Feb 9, 2022

@wader It costed to me around $0.07 to build the arm64 image yesterday.

👍 thanks for testing, ill buy you a beer if we ever end at the same conference! so one beer is like 70 static-ffmpeg builds :)

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.

None yet

3 participants