Independent build

[marvinmarnold]

Why
The hm-pktfwd build process is confusing. This is one of two proposals on how to structure the Dockerfile in order to improve things. We have decided to split up the build process by repo instead of having a mono-Dockerfile in hm-pktfwd.

How
Builds libloragw only and outputs to /opt/output to be retrieved by packet_forwarder and hm-pktfwd.

References

• Related to: Independent build packet_forwarder#2
• Related to: feat: copy process from hm-pktfwd sx1302_hal#1
• Related to: Refactor build process hm-pktfwd#59
• Closed all-in-one proposal: All-in-one build total refactor hm-pktfwd#58
• Incorrectly opened here originally: Independent build Lora-net/lora_gateway#172

[marvinmarnold]

@shawaj thanks for pointing out the original wrong PR location. Both this and NebraLtd/packet_forwarder#2 are meant to be drafts.

[vpetersson]

LGTM so far structure wise.

[vpetersson]

We should probably use releases here and reference the releases in --from=lora_gateway line in packet_forwarder? Wdyt?

[marvinmarnold]

We should probably use releases here and reference the releases in --from=lora_gateway line in packet_forwarder? Wdyt?

Using releases makes sense but I'm not sure how to do that automagically. For the moment, I'm just using commit hashes like we do in helium-miner-software.

[shawaj]

We should probably use releases here and reference the releases in --from=lora_gateway line in packet_forwarder? Wdyt?

Using releases makes sense but I'm not sure how to do that automagically. For the moment, I'm just using commit hashes like we do in helium-miner-software.

We can automatically tag and release easily as per

https://github.com/NebraLtd/hm-miner/blob/79923ea6ab73a69c446a99cbad658e6453d97c9d/.github/workflows/check-latest-release.yml#L44-L59

But I guess this would also require a semver action such as:
https://github.com/marketplace/actions/git-semantic-version

Otherwise we would have to manually tag/release.

Maybe easier to just use the commit SHA like you have already?

[shawaj]

Probably don't need this

Can just use the same reset script as for the sx1302 instead of copying multiple

See also NebraLtd/hm-pktfwd#59 (comment)

[marvinmarnold]

I do see some small differences between the scripts but I'm unclear how significant they are. I agree we should only copy one file if the differences are not important.

1. sx1301 sets input during init but sx1302 doesn't

2. sx1301 stop doesn't reset but sx1302 does

Want to make the call @shawaj?

[shawaj]

1. the reason they are doing that is because they seem to be using GPIO7 for both the reset pin and as the SPI chip select pin. I don't understand why they did this - it is a bizarre choice. But we do not need to set any inputs on the reset pin as it is only used for reset and nothing else

2. iot_sk_init() in sx1301 folder is the same function essentially as init() and reset() together in the sx1302 function. so this is doing the same thing just in separate functions.

So I would say the sx1302 one makes more sense to keep

[marvinmarnold]

1. Cool
2. @shawaj Not sure we are talking about the same thing. The relevant code is in a case statement to handle start and stop commands differently. I agree that iot_sk_init() vs init()+reset() are functionally the same for start. But for stop, the sx1301 version is missing the call to reset/init all together. That said, I'm OK using the sx1302 code only and will make that change.

[shawaj]

@marvinmarnold i don't know exactly why there is a need to reset before the term() command - to be honest I think that is unecesary in sx1302 - but it also will not harm so may as well leave it in (for either sx1301 or sx1302)

[marvinmarnold]

We can automatically tag and release easily as per

https://github.com/NebraLtd/hm-miner/blob/79923ea6ab73a69c446a99cbad658e6453d97c9d/.github/workflows/check-latest-release.yml#L44-L59

But I guess this would also require a semver action such as: https://github.com/marketplace/actions/git-semantic-version

Otherwise we would have to manually tag/release.

Maybe easier to just use the commit SHA like you have already?

Let's prioritize getting the current work over the line. The steps you laid out should work. Created a new issue to track this work.