Skip to content
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

Open
cleverer opened this issue May 29, 2020 · 5 comments
Open

Speedup seeding #9

cleverer opened this issue May 29, 2020 · 5 comments

Comments

@cleverer
Copy link
Member

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
Copy link

simfeld commented Jun 1, 2020

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
Copy link
Member Author

cleverer commented Jun 1, 2020

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
Copy link
Member

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
Copy link
Member Author

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants