While the original intent of the `secretsocket` script was to have `rbw`
run outside the `xactfetch` container, that is only useful during
development; both processes need to run in the container in Kubernetes.
With the addition of ancillary scripts like `entrypoint.sh`, the `COPY .`
instruction in the build stage results in a full rebuild of the final
image for every change. To avoid this, we now only copy the files that
are actually required to build the wheel. The other scripts are copied
later, using an intermediate layer. This avoids needing a `COPY`
instruction, and therefore a new layer in the final image, for each
script. Hypothetically, we could use `RUN --mount=bind` and copy the
files with the `install` command, but bind-mounting the build context
doesn't actually work; SELinux prevents the container builder from
accessing the source directory directly.
If the `SECRET_SOCKET_PATH` environment variable is not set, or refers
to a non-existent path, then we assume we need to manage the
`secretsocket` server ourselves.
Earlier this week, `xactfetch` stopped being able to log in to the Chase
website. After logging in, the website just popped up a message that
said "It looks like this part of our website isn't working right now,"
with a hint that I should try a different browser. I suspect they have
enhanced their bot detection/scraping resistance, because the error
only occurs when `xactfetch` is run from inside a container. It happens
every time in that case, but never when I run it on my computer
directly.
After several hours of messing with this, the only way I was able to
get it to work is to use full-blown headed Chromium. Neither headless
nor headed Firefox works, nor does headless Chromium. This is a bit
cumbersome, but not really a big deal. Headed Chromium works fine in
an Xvfb session.
Dustin