Dove conservare il sorgente dell'importatore personalizzato?

Hi,

I have been working on a custom importer so that I can import data from our Woltlab forum into Discourse. I did that by running Discourse directly on my development machine without Docker, and now I have a bunch of files in script/import_scripts/ that contain my migration code. Those files live in a fork of the official Discourse GitHub repository for now.

I would like to migrate to an official, docker based install now, but I will need my importer code to be available in the new installation for some time, as the migration will need to be done in a rolling fashion. If possible, I would like to keep the importer code in a separate repository and make it available in the production install in a clean manner.

My knowledge of Rails is limited, so I may be missing an obvious approach. Can anyone point me into the right direction?

Thanks!
Hans

2 Mi Piace

In this case I would suggest one of the following:

  1. during the rolling migration, base your instance off your fork. If you want to include new functionality, just sync your fork with upstream on a regular basis. When the migration is done, switch back to discourse/discourse

  2. clone your repo outside docker and copy the files in. Do it after a rebuild, otherwise the precompile script will find the repository unclean and the build will take much longer.

I think #1 would be the best.

4 Mi Piace

Thanks, @RGJ! I’ll go that route.

I’ve changed the repository URL inside of the docker container and was able to run my importer. When I ran ./launcher rebuild app, however, the repository was reset to the upstream. I’ve looked at the Dockerfile and it seems to hard code the repository path, but it also does not seem as if the base container is built locally, so changes to the Dockerfile don’t have the desired effect. Is there any sanctioned way how I can make this work?

I suggest working with two containers. You can do so by creating a copy of your current app.yml file (you can find it in /var/discourse/containers) and renaming it to something else like import.yml. Then update the version parameter to your custom importer branch.

params:
  version: your-branch

Anytime you need to run the import, stop the app container, start the import container and run the script inside the import container. If significant changes were made in Discourse, you may need to rebase your branch with the latest commit from core, and rebuild the container.

cd /var/discourse
./launcher enter import

# want to switch to a different branch?
su discourse -c 'git checkout <branch>'

# want to pull new code?
su discourse -c 'git pull'

Once you are done with the migration, stop the import container and restart the app one.

cd /var/discourse
./launcher stop import
./launcher start app

Credits to @gerhard who taught me how to do all this :backhand_index_pointing_up:

3 Mi Piace