scout-ch / midata-cypress

2 stars 0 forks source link

Speedup seeding #9

Open cleverer opened 4 years ago

cleverer commented 4 years ago

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.

simfeld commented 4 years ago

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.

cleverer commented 4 years ago

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.

carlobeltrame commented 4 years ago

Using GitHub Actions, it is possible to set up scheduled polling on the upstream repositories. See the sync-devel job here: https://github.com/carlobeltrame/ecamp3/blob/devel/.github/workflows/sync.yml To do this, we'd need a fork of all upstream repositories in this organization, to which we add the github workflow config file to keep them always up to date. Then, we can set up our own reactive CI that runs whenever our forks are (automatically) pushed to. But that might be worth its own issue.

cleverer commented 4 years ago

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…

carlobeltrame commented 4 years ago

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.