search

OpenGrok / docker

WARNING: this repository is archived !
58 stars 31 forks source link

Provide release candidate images #18

Closed edigaryev closed 5 years ago

edigaryev commented 5 years ago

Currently this repository provides a single OpenGrok 1.0 image (using the latest tag) that lags behind the latest RC release by more than a year.

Considering RC's are pretty stable, it'd be nice to have a way to quickly deploy fresh OpenGrok with the recent features and bug-fixes.

A different tag can be certainly used to achieve that and Docker Hub seems to support multiple Dockerfile's: https://stackoverflow.com/a/44796846/9316533

tjwalton commented 5 years ago

I am also interested in this and made the obvious changes in https://github.com/tjwalton/docker-1/commit/186b8328c06e0081e917dde9a68dc71ecc41591a, but it doesn't work. I get an error java.io.FileNotFoundException: Unable to determine source root path. Missing configuration?. I think I might just need to make a configuration file but any suggestions would be appreciated.

vladak commented 5 years ago

This means that the web app did not receive the configuration from the indexer. The config is sent at the end of the indexing using the RESTful API (-U option of the Indexer). This could be related to the / vs. /source, however looking into the changes, I don't see anything standing out.

vladak commented 5 years ago

Side comment: In general, the trouble with release candidates is that they might require reindexing from scratch. This is no longer that case with 1.1-rc's however could be in the future. Possibly we can augment release metadata with a tag that could be checked by the docker script.

tjwalton commented 5 years ago

@vladak: thanks for your helpful comments on my commit. With those changes, I now have a working 1.1 image.

Side comment: In general, the trouble with release candidates is that they might require reindexing from scratch. This is no longer that case with 1.1-rc's however could be in the future. Possibly we can augment release metadata with a tag that could be checked by the docker script.

As I understand it, the indexing data is written to /data. Therefore, unless this is mounted, any new container will index from scratch. So I think this is okay with the default instructions.

I have opened #19 with my changes where we can discuss any more specifics.

edigaryev commented 5 years ago

Thanks, changes merged in #19 pretty much nailed it.

Also I've done some further steps regarding automation so that manual version bumping won't be neccessary after each RC release, see #20.

vladak commented 5 years ago

closed via #20