Update .dappnode_profile

[alexpeterson91]

update dappmanager to v0.2.59 published with release of last week's core release of v0.2.64

I keep having to manually mark published releases as latest, today i had to do the dappmanager and the core, both a week after publication still marked as pre-releases. I had to do the same for various versions and components of the last few core updates, why isnt this done automatically? is there a way to have a workflow check the published version on the smart contracts and automatically mark that release as latest?

[alexpeterson91]

Also needed to update ISO link for debian, link is no longer accessible since 11.5 has been moved to archive and supplanted by 11.6. replaced URL target with the archive link to 11.5 netinst ISO

[dapplion]

why isnt this done automatically?

I would require some watcher script that marks a release as not draft once it sees that specific release published in the blockchain. That has to be develop and I assume there hasn't been bandwith

[alexpeterson91]

why isnt this done automatically?

I would require some watcher script that marks a release as not draft once it sees that specific release published in the blockchain. That has to be develop and I assume there hasn't been bandwith

Yeah most likely. also this didn't used to be an issue it's only started happening more lately. And there's been way more activity so it makes sense that it's harder for edu to keep up manually. It just makes working on installer related stuff a bit more complicated.

[pablomendezroyo]

To generate a release in the installer repo it is needed to trigger manually a gha that receives as inputs the core packages versions, check out https://github.com/dappnode/DAppNode/blob/8c66e1b4eaf661ab6f7ce41fe199763142866bb7/.github/workflows/release.yml#L4. The workflow uses these versions to edit the dappnode_profile with the provided versions (check out https://github.com/dappnode/DAppNode/blob/8c66e1b4eaf661ab6f7ce41fe199763142866bb7/.github/workflows/release.yml#L60) and execute compose up to create the release.

The main issue here is that the edit of the profile is not been merged/PR so although the release is been properly generated, the src code is not changing. So I would suggest to add a commit/PR in the profile on every release action

is there a way to have a workflow check the published version on the smart contracts and automatically mark that release as latest?

I wouldn't do this, we want the capability to generate releases with not only the latest core versions. Also, these releases are generated from Github core repos

[alexpeterson91]

To generate a release in the installer repo it is needed to trigger manually a gha that receives as inputs the core packages versions, check out

https://github.com/dappnode/DAppNode/blob/8c66e1b4eaf661ab6f7ce41fe199763142866bb7/.github/workflows/release.yml#L4

. The workflow uses these versions to edit the dappnode_profile with the provided versions (check out

This ive since learned. I've started to start the workflow a few times but never actually ran it (we/I need to get an experimental asset ISO of the NUC 12 compatible branch up and posted as such, we have a lot of users who cant get past install on their NUC12s since theres no network card drivers installed and by far the most elegant solution ive seen is just releasing an experimental version with warnings about its experimental temporary nature, hopefully we can resolve this fully, the right way by the time after Debian 12 is released in march or w/e, till then we have at least a dozen users probably a good deal more who need this ISO in order to even install Dappnode, We gotta give them the opportunity).
(Sorry got pretty far off topic there just wanted to give background as to why ive been trying to be on top of this "issue" or rather complexity, and what my intentions/goals are)

I was under the impression that if i manually triggered the workflow with the branch and versions i select it would create an entire release and core. Can i just copy the workflow/ fork the repo to my own Organization to run CI and GHA to keep my experiments separate from production etc? just so i don't go mucking about in the production stuff. Problem im facing is that when i just build the ISO with the installer repo i either need to install a ton of dependencies in order to rebuild every core DNP image when BUILD=TRUE flag is enabled (I've tried on a handful of systems over the course of a year + and it would always fail while regenerating images) so I'm stuck with just pulling the content with build=false, which whenever i build it it pulls a very old core like 2.50 and some older versions for IPFS, HTTPS, and the Dappmanager obviously so it needs a bunch of updates right away for core software. is there a way to update that? I don't know what its pulling from but its many many months out of date, doesn't need to be kept totally current but 2.50- 2.66 is a TON of major changes so a manual update of the profile's default value's may we warranted, let me know what you think, thanks.

And more importantly am i right to assume that running that workflow dispatch with entered values for versions etc, shouldn't be used by me to generate a NUC 12 ISO because it will just generate a new release version correct? or can I use the workflow to generate ISOs from whatever branch i choose, and whatever versions of core software etc without messing up the production releases so long as I name them differently? or will that just mess with SemVer?

[pablomendezroyo]

Outdated