Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

🚀 Separation of concerns by branches #294

Open
AyAyEm opened this issue Dec 10, 2021 · 3 comments
Open

🚀 Separation of concerns by branches #294

AyAyEm opened this issue Dec 10, 2021 · 3 comments
Labels
Scope: Data How data is represented or cleaned up Severity1: Critical The defect affects critical functionality or critical data. Type: Enhancement Improves existing feature

Comments

@AyAyEm
Copy link
Member

AyAyEm commented Dec 10, 2021

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.

@AyAyEm AyAyEm added Type: Enhancement Improves existing feature Scope: Data How data is represented or cleaned up Severity1: Critical The defect affects critical functionality or critical data. labels Dec 10, 2021
@AyAyEm
Copy link
Member Author

AyAyEm commented Dec 10, 2021

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?

@TobiTenno
Copy link
Member

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

@AyAyEm
Copy link
Member Author

AyAyEm commented Dec 10, 2021

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.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
Scope: Data How data is represented or cleaned up Severity1: Critical The defect affects critical functionality or critical data. Type: Enhancement Improves existing feature
Projects
None yet
Development

No branches or pull requests

2 participants