Skip to content

🚀 Separation of concerns by branches #294

Description

@AyAyEm

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.

Activity

  1. added
    Scope: DataHow data is represented or cleaned up
    Severity1: CriticalThe defect affects critical functionality or critical data.
    on Dec 10, 2021
  2. AyAyEm commented on Dec 10, 2021

    @AyAyEm
    MemberAuthor

    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?
  3. TobiTenno commented on Dec 10, 2021

    @TobiTenno
    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
  4. AyAyEm commented on Dec 10, 2021

    @AyAyEm
    MemberAuthor

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Scope: DataHow data is represented or cleaned upSeverity1: CriticalThe defect affects critical functionality or critical data.Type: EnhancementImproves existing feature

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions