Repository navigation
Add support for building Docker images (locally and in GitHub Actions) - #10
Conversation
| ENV TC_AGREEMENT=yes | ||
| ENV NETWORK_OPERATIONSAPI_PORT=9925 | ||
| ENV LOGGING_STDSTREAMS=true | ||
| ENV REPLICATION_HOSTNAME=localhost |
There was a problem hiding this comment.
This will still work but i think with v5 we are moving over to NODE_HOSTNAME
There was a problem hiding this comment.
I think we still support replication.hostname though. I think.
...in Dockerfile
| ENV TC_AGREEMENT=yes | ||
| ENV NETWORK_OPERATIONSAPI_PORT=9925 | ||
| ENV LOGGING_STDSTREAMS=true | ||
| ENV REPLICATION_HOSTNAME=localhost |
There was a problem hiding this comment.
I think we still support replication.hostname though. I think.
|
|
||
| WORKDIR /home/harper | ||
|
|
||
| USER harper |
There was a problem hiding this comment.
Based on https://harperdb.slack.com/archives/C3Z2T1QAZ/p1771516627918229?thread_ts=1771508030.217909&cid=C3Z2T1QAZ, I thought we had decided not to make the user name change yet (stay with harperdb), due to more complicated fabric changes?
There was a problem hiding this comment.
Haha, I drew the exact opposite conclusion from (trying to) read that same thread. Happy to revert though if it makes Fabric devops' lives easier in the short term!
| @@ -0,0 +1,9 @@ | |||
| .git/ | |||
| /dist/ | |||
There was a problem hiding this comment.
We don't want dist and node_modules in the docker image? I am probably misunderstanding.
There was a problem hiding this comment.
They get created inside the image via the npm run package call in the Dockerfile. We don't want whatever versions of those might be hanging around on whatever machine is running the build.
cb1kenobi
left a comment
cb1kenobi
left a comment
There was a problem hiding this comment.
Looks awesome! I love the slack message on success/failure. I'd like to borrow it. :)
I also learned about the RUN <<-EOF syntax. I'm old school and used to the && chaining.
| token: ${{ secrets.SLACK_BOT_KEY }} | ||
| payload: | | ||
| { | ||
| "channel": "#development-ci", |
There was a problem hiding this comment.
FWIW, for rocksdb-js, I put the channel id in a GH secret since that repo is public. Not sure if we want to do the same, but this should do the trick:
| "channel": "#development-ci", | |
| "channel": "${{ secrets. SLACK_CI_CHANNEL_ID }}", |
There was a problem hiding this comment.
Does the channel name need to be kept secret? You need credentials to access it either way. So I was assuming it did not.
kriszyp
left a comment
kriszyp
left a comment
There was a problem hiding this comment.
I assume you will make the user name change, but this looks great!
Add DESIGN.md invariant #10 capturing the three reconnect-recovery drivers (close-handler/forceReconnect retry, receive watchdog, main-thread wedge reconcile), the createWebSocket-rejection trap they all shared, and the two backstop subtleties (never-opened entry uses connected!==true + createdAt; the reconcile must forceReconnect only a reused connection on a per-db wedged entry). Hard-won recovery-layering knowledge that wasn't previously captured. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Add DESIGN.md invariant #10 capturing the three reconnect-recovery drivers (close-handler/forceReconnect retry, receive watchdog, main-thread wedge reconcile), the createWebSocket-rejection trap they all shared, and the two backstop subtleties (never-opened entry uses connected!==true + createdAt; the reconcile must forceReconnect only a reused connection on a per-db wedged entry). Hard-won recovery-layering knowledge that wasn't previously captured. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
4 participants
One change that I'm sort of subtly proposing in here is that we do not set a default
HDB_ADMIN_PASSWORDbut instead require (and will document) that users set that when they run the container via e.g.-e HDB_ADMIN_PASSWORD=whatever. This is a pretty common security practice with Docker containers.