[ ] I’m using docker compose setup, with modifications (modified .yml files, third party plugins/themes, etc.) - if so, describe your modifications in your post. Before reporting, see if your issue can be reproduced on the unmodified setup.
[ ] I’m not using docker on my primary instance, but my issue can be reproduced on the aforementioned docker setup and/or official demo.
No modification on the docker-compose and only the 4 necessary variables in the .env for access and login:
ADMIN_USER_PASS
ADMIN_USER_ACCESS_LEVEL
TTRSS_SELF_URL_PATH
HTTP_PORT
Tiny Tiny RSS version (including git commit id): 1be156408af4f9291790dbda7131fd99369ca48f
Platform (i.e. Linux distro, Docker, PHP, PostgreSQL, etc) versions:
I’m not sure how the app container (image: cthulhoo/ttrss-fpm-pgsql-static:latest) get the content of the repo in its var/www/html folder but it did not generate a .git in my instance.
If you use a build instead of an image you could add thoses variables in your container environement and it will work.
First you can get the .git from the repo: git clone --no-checkout https://git.tt-rss.org/fox/tt-rss.git
then put the necessary variables in a file:
did you do docker-compose build or docker-compose pull? maybe build: stuff should be removed from the default compose file and left in a FAQ entry for alternative platforms or something.
self-built images showing unsupported would be technically correct - i don’t really want to support something that didn’t go through my automated testing and build pipelines.
adding some kind of solution to show version info for self-built images is a good idea tho.
Yes i removed the build: in order to pull the images. and maybe you should remove it from web-nginx: too.
Maybe adding a mention (unsuported build) after the version would be better than showing no version?
I think that way because since your versionings are based on the commit hash, even if you use an unoficial build, that build will still have an “official” version.
good point. having it there shouldn’t stop you from pulling but i guess it could be confusing.
yep. would be easier to figure out things in case of questions.
e: i’ll link your above post with .version env file in the FAQ because i have no idea how to do this using compose, .git repo is not passed as docker context anymore so
this won’t work with docker compose auto-cloning off git repo though. oh boy.
looks like docker compose build omits passing .git to build context when building from the repository so there’s literally no way to figure out version information.
i’m not going to waste any more time on this. use amd64 or suffer.
yeah you’ll have to prepare the file manually using a shellscript or something, .env files are just text, they won’t run commands (and neither would docker compose).
If you use the 2 code blocks i gave above in your shell (just copy / paste the lines in the same directory your docker-compose.yml is) it will generate the .version file.
By default, BuildKit doesn’t keep the .git directory when using Git contexts. You can configure BuildKit to keep the directory by setting the BUILDKIT_CONTEXT_KEEP_GIT_DIR build argument. This can be useful to if you want to retrieve Git information during your build: