Update of dockerhub image

[Nanquitas]

Hey :)

Could you update the devkitarm image from your dockerhub please ?
libctru went to 1.6 since the image was built.

Thanks!

[Margen67]

@WinterMute

[WinterMute]

Finding a good spot to stop & update dockers is always difficult. Fresh set done today though.

[Margen67]

Perhaps updates could be automated? https://docs.docker.com/docker-hub/builds/

[sergiou87]

Sorry to bother, but I could use an update too since I need the changes in devkitPro/SDL#57

Unless it's ok that I run pacman -Sy && pacman -S dkp-libs/3ds-sdl from the docker image, whatever is more convenient / less of a hassle to you 😄

(This wouldn't happen on every commit of my project, only when I make a beta build or a release build)

[WinterMute]

Perhaps updates could be automated? https://docs.docker.com/docker-hub/builds/

The problem is, as always, finding a good spot to lock things in and roll a new docker image. If I know I have another 3 or 4 libraries due to be updated within the next week or so then I'm reluctant to roll a release now then do another a few days later. Rolling new toolchains and updates for the main libraries (i.e. libnds, libctru, libogc, libnx etc) seems to always result in a brief flurry of PRs and/or bug reports that people are suddenly reminded they've been sitting on. I also like to let things settle for a week or so to make sure we haven't messed something up that's going to mean another release.

It seems like a massive waste of resources to be updating docker images for every tool and library release too. I'd rather batch them if possible and try to avoid running updates on the dockers too often. There's a climate crisis and we should all be trying to save energy where we can.

[Nanquitas]

I think that automating a new update of the docker images on tags / release is still more efficient.
I mean, if we can always rely on one source (devkitPro team) for the images then ultimately they'll become the only one needed.

But when we can't then multiple developers create their own at random point of time.
Except, those won't be updated in the long run, so at some point a new dev that needs an update will again create a new image etc.

In the end, you'll have multiple old images rotting here and there.

A single provider always up to date which you can rely on seems more efficient to me.

But well, in the end it's your decision. ;)

[WinterMute]

@Nanquitas tags of what releases though? We have 144 library packages and 23 tool packages. There are probably more on the way. What if I update 10 in a day? 20?

If I have a bunch of things in progress I'm probably not doing dockers until I'm done and every opened ticket demanding updated dockers delays any update that's going to happen.

It would be better if some people exercised a bit of patience and didn't demand every commit of every repository produce a binary they can instantly complain about being broken.

It's an absurd and pointless waste of resources.

This is a massive, massive issue tbh. Nobody needs an update instantly and you should stop demanding them and/or pandering to those who demand them.

[Nanquitas]

Hey there, I'm just trying to have a conversation here, I'm not attacking anyone. ;)

You're right when you say that we most likely don't need an hourly update for every package.
Which is why I talked about a on-release and/or tag update, you're still in command of when to trigger the update.

Realistically speaking, there's not that much releases on a base of 12 months. There's a lot of work / commits, true, but not much release.

We're talking about updating too much as if we're asking an update at each commits but the latest devkitarm' image was 2 years old.
I'm pretty sure there was some worthwhile updates since then.

Why I think that a unique up to date provider is useful:
- We're sure to work with latest tools from a trusty source
- We can then work on a general "workflow / actions / ci" repository and starts to "standardize" the devops for homebrews
- It might help ensuring that homebrews are up to date
- It might also decrease the risks of lambda users using "harmful builds"

Sure, docker wasn't used that much in the scene(s) until now, but tools using it are deploying and made easy to integrates / use, so I think it's worthwhile to at least have a discussion about it and try to arrive to something workable.

(Maybe something like a monthly update ?)

I think that with things like github's codespace, it might be even more interesting / needed.
You can code and release bugfixes from anywhere without the need to install the whole devkitarm sdk. I for sure am interested in it.

Alright, that's just my thoughts on the matter and again, I'm not asking for an immediate solution but more like an open discussion about the needs, constraints and what's doable or not.

Thank you btw, I didn't know the verb "pander", at least I have learned something out of this. ;)

[AleixMT]

@Nanquitas very reasonable and time-optimizing feature request.

PD: Monthly update? if you have an automated workflow you can even build nightly images on every commit. I do not see why not. Write the pipeline once and you'll be able to build automatically forever.

Would you accept a PR @WinterMute if we work on it?

Thank you

[WinterMute]

Would you accept a PR @WinterMute if we work on it?

No. The images are updated adhoc because we update and add components as needed. We don't want to trigger a workflow for every single component we add/change because we often have several to do at roughly the same time and we don't want an automated workflow to run at set intervals if nothing has changed.

We now have 263 library packages and 37 tool packages with varying degrees of interdependency.

This is actually NOT a "very reasonable and time-optimizing feature request." please don't ask again.