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

Improve CI/build/pre-built #118

Open
konsumer opened this issue Mar 16, 2022 · 1 comment
Open

Improve CI/build/pre-built #118

konsumer opened this issue Mar 16, 2022 · 1 comment
Labels
raylib4 Issues related to migration from raylib 3.5 to 4.

Comments

@konsumer
Copy link
Collaborator

konsumer commented Mar 16, 2022

I think we can improve CI a bit, and make the prebuilt system work better overall

  • Just build pre-builts once for each platform (no multiple node versions needed)
  • run tests as separate action on more node versions (for example include 10 and 17, since it's current)
  • Get non-x86-64 builds working (pi, M1)
  • move artifacts to tagged release (or figure out a better way to find the "best" artifact to use for a pre-built)

"best" artifact

We should have fall-through logic for choosing the best version for a supported platform/arch.

graph TD
    ENV{Is an env-var set to force build?}
    FS{Is it already built locally in target dir?}
    GIT{Is this a git repo?}
    TAGGED{Is this tagged with something already in releases?}
    PKG{Is this package.json version in releases?}
    
    BUILD[Build using cmake]
    RELEASE[Download github release artifact]
    
    ENV --> |yes| BUILD
    ENV --> |no| FS

    FS --> |yes| FS_USE(use that)
    FS --> |no| GIT

    GIT --> |yes| TAGGED
    GIT --> |no| PKG

    TAGGED ==> |yes| RELEASE
    TAGGED ==> |no| PKG

    PKG --> |yes| RELEASE
    PKG --> |no| BUILD

Loading

Diagram is a bit crazy, but I think this would cascade correctly. I think we could make tags & branches build in CI, too, so if you don't set the env-var to force build, you can use the pre-built for that branch (like use whatever is the current raylib4-0.8.1 build for your platform, rather than fall right through to building.

@konsumer konsumer added the raylib4 Issues related to migration from raylib 3.5 to 4. label Mar 16, 2022
@konsumer
Copy link
Collaborator Author

If you want to modify the diagram, here is the source I used:

graph TD
    ENV{Is an env-var set to force build?}
    FS{Is it already built locally in target dir?}
    GIT{Is this a git repo?}
    TAGGED{Is this tagged with something already in releases?}
    PKG{Is this package.json version in releases?}
    
    BUILD[Build using cmake]
    RELEASE[Download github release artifact]
    
    ENV --> |yes| BUILD
    ENV --> |no| FS

    FS --> |yes| FS_USE(use that)
    FS --> |no| GIT

    GIT --> |yes| TAGGED
    GIT --> |no| PKG

    TAGGED ==> |yes| RELEASE
    TAGGED ==> |no| PKG

    PKG --> |yes| RELEASE
    PKG --> |no| BUILD

set the language for code-block to mermaid and it will draw it. You can edit it here

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
raylib4 Issues related to migration from raylib 3.5 to 4.
Projects
None yet
Development

No branches or pull requests

1 participant