Lightnode docker

[cody-littley]

Why are these changes needed?

Create a docker image suitable for running the light node on a raspberry pi.

Checks

• I've made sure the lint is passing in this PR.
• I've made sure the tests are passing. Note that there might be a few flaky tests, in that case, please comment that they are not relevant.
• Testing Strategy
  • hand tests
  • Unit tests
  • Integration tests
  • This PR is not tested :(

[mooselumph]

Would it make sense to use the commit that is currently checked out? Curious about the thought process here

[cody-littley]

I'm open to that idea, but we should weigh pros and cons.

This build process clones the repo into the docker image, as opposed to using the copy on the host file system. This adds extra overhead. The reason I took this step was that I wanted to avoid uncommitted local changes accidentally making their way into the resulting docker file, as well as requiring an explicit choice when it comes to choosing which version to build. But there is certainly additional friction to the developer in doing it this way. Let's discuss.

[cody-littley]

Per our discussion, I've changed this so that it instead builds against the code that is checked out locally (as opposed to cloning the code inside the docker file).

[anupsv]

In general, are we going to publish these docker builds as part of releases? If so, we should consider signing the containers and GHCR does enable this.

[cody-littley]

@anupsv

In general, are we going to publish these docker builds as part of releases? If so, we should consider signing the containers and GHCR does enable this.

I'm guessing the answer is "yes", although I haven't spent much time yet thinking about releases. Would it be ok with you if we addressed this as a stand alone task? This docker image will be useful during testing as we do development work.

[anupsv]

@anupsv

In general, are we going to publish these docker builds as part of releases? If so, we should consider signing the containers and GHCR does enable this.

I'm guessing the answer is "yes", although I haven't spent much time yet thinking about releases. Would it be ok with you if we addressed this as a stand alone task? This docker image will be useful during testing as we do development work.

Yep thats fine.

[mooselumph]

I think a worthwhile optimization would be the following sequence:

1. copy go.mod
2. Run go mod download
3. Copy the remainder of source
4. Run build

This would prevent having to redownload the go modules every time the source changes (as long as modules don't change)

[cody-littley]

Very good suggestion. Change made.