Fetching the released migrations pollutes the local repo #6
Labels
Comments
|
We had a few different versions of this. We used to hit the github API to get the migrations for a particular branch. We could resurrect that, but I think we were afraid of hitting the API rate limiter. Maybe that won't matter now that these specs are not running with every PR to the core repo? |
Fryguy
added a commit
to Fryguy/manageiq-schema
that referenced
this issue
Jun 21, 2017
This reverts the released migrations to using the GitHub API as was done in 9fba1a4. The concern for the GitHub rate limits in 9568c7a is no longer a problem now that migrations are in their own repo which should have much less churn, unlike the main manageiq repo where the migrations would run on *every* PR. Fixes ManageIQ#6
Fryguy
added a commit
to Fryguy/manageiq-schema
that referenced
this issue
Jun 22, 2017
This reverts the released migrations to using the GitHub API as was done in 9fba1a4. The concern for the GitHub rate limits in 9568c7a is no longer a problem now that migrations are in their own repo which should have much less churn, unlike the main manageiq repo where the migrations would run on *every* PR. Fixes ManageIQ#6
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When the migrations lived in ManageIQ proper, fetching a different branch locally was ok, because it was the same repo. Now that the schema has been separated out, fetching the ManageIQ/manageiq code into the ManageIQ/manageiq-schema repo pollutes the repo with the remote branches and tags. Unfortunately those tags will collide, for example when we cut gaprindashvili-1 on both repos, then try to fetch, you will get duplicate tag names, and I have no idea what will happen. We need an alternative now.
cc @carbonin
The text was updated successfully, but these errors were encountered: