Added automation for light hotspots

[MuratUrsavas]

Also removed necessity for upfront I2C device report. Now a single release could be used for all of the devices.

Issue
(#399)

• Summary:

How

• Removed upfront device report necessity
• Escalated gatewayrs container privileges
• Removed per device type fleet for testnets
• Removed all matrices and made deployment workflows simpler
• Added documentation for necessary IP ports
• Removed all docker-compose outputs as they always needed to be created again and creating unnecessary steps in workflows

Checklist

• Tests added
• Cleaned up commit history (rebase!)
• Documentation added
• Thought about variable and method names

[shawaj]

Removed all docker-compose outputs as they always needed to be created again and creating unnecessary steps in workflows

i think it is useful to keep these, so we can easily see from github the latest version (as well as the fact we need to push that to the relevant balena openfleets directories)

also, i think we need to keep device arch (the reason we added that is to support 5g in here further down the line which uses amd64)

the only way around that would be to put arch in hm-pyhelper and use it as part of the workflows in this repo as per #336

[MuratUrsavas]

i think it is useful to keep these, so we can easily see from github the latest version (as well as the fact we need to push that to the relevant balena openfleets directories)

I'm against keeping any automated output files in the repo. IMHO these are just unnecessary steps making things complicated. Also they include old information (previous commit). If any developer changes something locally and pushes manually to a fleet, the information would be incorrect. Without a compose file, any of a new developer would understand the necessity to create one and refer to readme.

Long story short, I'm still on the remove side.

also, i think we need to keep device arch (the reason we added that is to support 5g in here further down the line which uses amd64)

the only way around that would be to put arch in hm-pyhelper and use it as part of the workflows in this repo as per #336

As of now nothing was referencing to the architecture. So removing the extra information from settings.ini made things a lot simpler. If we'd need an architecture variation some day, we'd solve it like your suggestion (#336)

[shawaj]

If any developer changes something locally and pushes manually to a fleet, the information would be incorrect.

We shouldn't be pushing manually to testnet or production fleets IMO.

Also, having a quick reference for debugging rather than having to generate one from a python script is very useful when errors arise.

And we need them for the other balena OpenFleets repos so I don't see any way around keeping them.

As of now nothing was referencing to the architecture. So removing the extra information from settings.ini made things a lot simpler. If we'd need an architecture variation some day, we'd solve it like your suggestion (#336)

Sure, for lights it's maybe not relevant as it won't be referenced.

We will need the arch stuff for 5g very soon though so we should bump that up.

[pritamghanghas]

If any developer changes something locally and pushes manually to a fleet, the information would be incorrect.

We shouldn't be pushing manually to testnet or production fleets IMO.

Also, having a quick reference for debugging rather than having to generate one from a python script is very useful when errors arise.

And we need them for the other balena OpenFleets repos so I don't see any way around keeping them.

As of now nothing was referencing to the architecture. So removing the extra information from settings.ini made things a lot simpler. If we'd need an architecture variation some day, we'd solve it like your suggestion (#336)

Sure, for lights it's maybe not relevant as it won't be referenced.

We will need the arch stuff for 5g very soon though so we should bump that up.

I also think build time access to arch might come in handy with dockerfiles down the line.

[MuratUrsavas]

I also think build time access to arch might come in handy with dockerfiles down the line.

The main idea is, add more complexity when it's needed. Not upfront.

[MuratUrsavas]

Also, having a quick reference for debugging rather than having to generate one from a python script is very useful when errors arise.

And we need them for the other balena OpenFleets repos so I don't see any way around keeping them.

As of now nothing was referencing to the architecture. So removing the extra information from settings.ini made things a lot simpler. If we'd need an architecture variation some day, we'd solve it like your suggestion (#336)

Sure, for lights it's maybe not relevant as it won't be referenced.

We will need the arch stuff for 5g very soon though so we should bump that up.

The next stop is changing the start script to full python and implement all of these with the help of hm-pyhelper. But this ticket is long overdue, it will be nice to move it to testnet and then tackle with all of those in the next step.

[kashifpk]

@MuratUrsavas - looks good to me.

[shawaj]

Looking again now. Sorry for delay

[shawaj]

The next stop is changing the start script to full python and implement all of these with the help of hm-pyhelper. But this ticket is long overdue, it will be nice to move it to testnet and then tackle with all of those in the next step.

Yeah makes sense. We can always change before merging gateway-rs stuff to mainline.

@MuratUrsavas all looks good to me other than the failing unit tests

[MuratUrsavas]

@MuratUrsavas all looks good to me other than the failing unit tests

The test failures showed up after the rebase. Those additions belong to @pritamghanghas so I didn't touch them to not to break anything.

[pritamghanghas]

@MuratUrsavas has to related to version change. It was working till about a couple of days back.

[pritamghanghas]

@MuratUrsavas removal of this line broke docker-compose. Please add it back.

[MuratUrsavas]

Arghh. @pritamghanghas it should be left as like this while testing. Didn't mean to remove that. Will open a quick PR.