So I modified my Dockerfile to use an entrypoint.sh and switched to a different branch than my main repo branch. I’m running into deployment issues now:
FROM ruby:3.1.2-alpine3.15 AS development
RUN apk add --no-cache --virtual build-dependencies \
build-base git zlib zlib-dev gcc g++ patch readline \
readline-dev autoconf automake libtool make gcompat
RUN apk add --no-cache tzdata postgresql-dev postgresql-libs chromium chromium-chromedriver curl
RUN mkdir -p /app
COPY . /app
COPY ./entrypoint.sh /usr/bin/entrypoint.sh
RUN chmod +x /usr/bin/entrypoint.sh
WORKDIR /app
RUN gem install debase-ruby_core_source && gem install debase -v '0.2.5.beta2'
RUN bundle install
FROM development AS production
RUN apk del build-dependencies
ENTRYPOINT ["/usr/bin/entrypoint.sh"]
EXPOSE 3000
CMD ["bundle","exec","rails","server","-b","0.0.0.0"]
Thanks. That appears to have worked, although now it appears the database connection is timing out.
So I made DATABASE_URL an alias of QOVERY_POSTGRESQL_Z079DACDF_DATABASE_URL
In the Development environment, so I’m not entirely sure what’s wrong there. I’ll do some additional testing. Perhaps a redeploy is needed.
Unfortunately your forum won’t let me embed further images.
So the app stack I’m testing using both SQL database and a caching server. So that DATABASE_INTERNAL address for the SQL database is now aliased as DATABASE_URL, but the Redis DATABASE_INTERNAL I have aliased as REDIS_URL.
App is up and running. Thanks. I can do some testing before I go on vacation now, and once I’m back look into the Github integration. Looks very promising, I like the idea of this being a developer-friendly layer over our existing tooling.