-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Speedup seeding #9
Comments
I like this idea. However, we would need some rule determining how often / when to rebuild the image from fresh seeds, if there are for example changes in the seed files or db migrations. |
I agree, but it actually is more of a problem of the docker build in general, as you can't use any repos for now. Silver bullet would be to have the hitobito repos trigger a build here, but 'uzzle itc would have to set that up. For now the idea is to rebuild, when there are changes in master and on tags aka. new hitobito versions. |
Using GitHub Actions, it is possible to set up scheduled polling on the upstream repositories. See the |
That would be an option, however I don't like to fork a repository just for CI… But I just realized renovate-bot supports git submodules. We could set it up in a way that automatically merges the changes which would automatically lead to a new CI run. It would also record the exact hitobito version of a specific git commit… |
Sure, if submodules are okay for you and a fork is not we can do that :) I don't really mind. Any way we do it, all we want to do is run our custom CI whenever something changes in a repo that isn't ours. The rest is implementation details. |
We could bake a dump of the freshly seeded db into a db image. That would require building a db image after having built the main container.
The text was updated successfully, but these errors were encountered: