Giters

WFCD / warframe-items

đŸ“˜ Get all Warframe items directly from Warframe's API. No more messy wikia scraping.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

:rocket: Separation of concerns by branches

AyAyEm opened this issue · comments

commented

Is your enhancement request related to a problem? Please describe.
No

Describe the upgrade you'd like
Separate the generated data from code.

Describe alternatives you've considered
Adding a specific orphan branch for the data builds and gitignoring the data folder in the other branches.

I think that a good view of changes made to the project will in the long term provide a better development experience because what we currently have is this:
image
almost 5000 commits in the master branch and it's just going to keep increasing adding code or not to the project.

commented

Things to consider for a solution:

  • When cloning for testing, it needs to build first?
  • If it doesn't need to build, from which branch the data is coming from?
  • How complex it would be to create a release?
commented

I like the idea, but a couple concerns of asks and things to consider:

  • the release CI job checks for path changes, which would be more difficult when combining parts from 2 branches
  • exisiting build commits would still be present unless we did a massive history rewrite, which is very problematic, and we'd definitely need to test on a fork, first
  • we would have to rewrite some page rules once this goes into effect to passively switch over the 301 redirect cdn we use for images
  • we would immediately break any/all people who directly pull the branch data... which i'm not opposed to, they shouldn't be doing it anyway. we have an api that is more fully featured than the direct data dump would ever be
  • this would also allow us to use a more generic default branch whenever desired without breaking CDN and/or dumpers
  • we'd need to maintain a change history going forward, as without history, we'd get massive untraceable breaks

ideas:

  • we could leverage submodules for the main branch to point to the last built commit of the data branch
  • npm postinstall script to init submodules would probably be viable as a way to init the changes, but it would mean we might need to do additional checks on the build commit to push an update for the submodule to allow easier contribution
commented

The release not necessarily would need to check for 2 branches, it could just check for let's say data branch and another CI script like build would also check the path for changes in build and it would build for the data branch.

Also i don't think it's necessary to remove the history of the bot changes.