1. 02 Jun, 2026 1 commit
  2. 01 Jun, 2026 1 commit
  3. 27 May, 2026 3 commits
  4. 18 May, 2026 2 commits
  5. 04 May, 2026 1 commit
  6. 27 Apr, 2026 1 commit
  7. 24 Apr, 2026 1 commit
    • Bogdan Mitrović's avatar
      Fix PathSegment.hashCode() not handling PathVerb.CLOSE (#1194) · 9b179119
      Bogdan Mitrović authored
      PathSegment.hashCode() threw RuntimeException("Unreachable") for
      PathVerb.CLOSE segments when used in hash-based collections such as
      intersect(). Added CLOSE case consistent with what equals() checks for
      CLOSE segments. Also removed the else branch since all PathVerb values
      are now handled. Added a test which fails unless CLOSE is handled in
      hashCode().
      
      ## Testing
      Ran test on awt locally — the new test `closedPathIntersectTest` fails 
      before the fix and passes after.
      
      ## Release Notes
      Fix crash when using closed paths in hash-based collections such as
      `intersect()`
      
      Fixes: [SKIKO-1038](https://youtrack.jetbrains.com/issue/SKIKO-1038)
      9b179119
  8. 23 Apr, 2026 2 commits
  9. 22 Apr, 2026 1 commit
  10. 17 Apr, 2026 1 commit
  11. 09 Apr, 2026 1 commit
  12. 07 Apr, 2026 1 commit
  13. 24 Mar, 2026 1 commit
  14. 23 Mar, 2026 1 commit
  15. 13 Mar, 2026 1 commit
  16. 06 Mar, 2026 1 commit
  17. 05 Mar, 2026 1 commit
  18. 03 Mar, 2026 1 commit
  19. 02 Mar, 2026 1 commit
  20. 26 Feb, 2026 3 commits
  21. 20 Feb, 2026 1 commit
  22. 19 Feb, 2026 4 commits
  23. 18 Feb, 2026 1 commit
  24. 17 Feb, 2026 3 commits
  25. 16 Feb, 2026 2 commits
    • Victor Kropp's avatar
      replace all remaining links to maven.pkg.jetbrains.space (#1167) · e2f8d173
      Victor Kropp authored
      All public links are updated to
      https://redirector.kotlinlang.org/maven/compose-dev
      Internal buildSrc links to maven directly to avoid unnecessary redirects
      
      Fixes SKIKO-1108
      e2f8d173
    • Ivan Matkov's avatar
      Refactor local Skia build to Gradle/Kotlin (#1163) · 3451c14e
      Ivan Matkov authored
      Previously:
      - The bash script required specifying `SKIA_VERSION` separately from
      `gradle.properties`, leading to version mismatches
      - Script hardcoded `SKIA_TARGET` default to `iosSim`, requiring manual
      override on non-macOS systems
      
      This change:
      - Added `skiaVersionFromEnvOrProperties` property and `printSkiaVersion`
      task. The bash script now queries Gradle for the version instead of
      maintaining its own default.
      - Target platform now defaults to current OS (`hostOs.id`) instead of
      hardcoded `iosSim`.
      - Introduced `BuildLocalSkiaTask` that handles Python build script
      invocation, architecture detection, and validation.
      - Added `SkiaTarget` enum centralizing platform-specific Gradle flags
      and architecture mappings.
      - Simplified bash script: Now focuses solely on git operations
      (clone/checkout skia-pack), delegating all build logic to Gradle.
      
      ### Usage
      ```sh
      # Version from gradle.properties, target auto-detected from OS
      ./build-with-local-skia.sh
      
      # Override either via environment variables
      SKIA_VERSION=m138-80d088a-2 SKIA_TARGET=iosSim ./build-with-local-skia.sh
      
      # Or use Gradle tasks directly
      ./gradlew prepareLocalSkiaBuild -Pskia.target=linux
      ```
      3451c14e
  26. 12 Feb, 2026 1 commit
    • Ivan Matkov's avatar
      Build Docker images locally when `Dockerfile`s change (#1161) · 1b3f124b
      Ivan Matkov authored
      Fixes [SKIKO-1103](https://youtrack.jetbrains.com/issue/SKIKO-1103)
      Properly handle Dockerfile changes in CI
      
      ### 1. Handle Dockerfile Changes in CI
      When a PR modifies both the `Dockerfile` and C++ source, CI must build
      the library against the **new** container logic before merging to catch
      compatibility issues.
      Workflows now detect `Dockerfile` changes and automatically build images
      locally before running tests. When no `Dockerfile` changes are detected,
      published images from `ghcr.io` are used.
      
      ### 2. Avoid GLIBC Mismatches: Run GitHub Actions Outside Containers
      Running GitHub Actions native steps (like `actions/checkout`) inside
      custom containers causes GLIBC version mismatches since GitHub's
      Node.js-based actions require newer GLIBC than Amazon Linux 2 provides.
      This change introduced new composite action `docker-skiko-run` that runs
      GitHub actions outside the container on `ubuntu-24.04` runner, and only
      executes build/test commands inside the Docker container via `docker
      run`.
      
      ### 3. Environment Alignment: Use `linux-compat` for GitHub Actions
      Builds
      GitHub Actions used Ubuntu 20.04 images with GLIBC 2.31, while TeamCity
      publishing used Amazon Linux 2 with GLIBC 2.26. This mismatch could mask
      GLIBC compatibility issues during PR validation.
      Most GitHub Actions workflows now use `linux-compat` (Amazon Linux 2).
      - Web builds are out of the scope here because emsdk requires newer
      GLIBC.
      - Cross-compilation is out of the scope because there is no simply way
      to get arm shared libraries to x64 image on AL2
      
      Note: TeamCity publishing should be updated to use `linux-compat` too
      
      ### 4. Introduce Orchestrator Workflows
      New orchestrator workflows compose existing test/build/docs workflows:
      - **`pull-request.yml`** - Runs on every PR: detects Docker changes,
      builds images if needed (dry-run), runs tests + publish dry run + docs
      validation
      - **`post-merge.yml`** - Runs on push to master/release: detects Docker
      changes, publishes images if changed, runs tests + publish dry run +
      docs publication
      
      So, we should have fewer "Run CI" temporary PRs now
      
      ### 5. Documentation as Pre-Merge Check
      Documentation builds now run inside the same `linux-compat` Docker
      environment used for library builds, and are validated as part of PR
      checks (previously only ran post-merge).
      
      
      ### 6. Docker Tags Use Branch Names
      Published Docker images are tagged with the branch name (e.g., `master`,
      `release/0.9.46`), so the release branches might publish its own version
      of the image. This way changes in `master` shouldn't prevent making a
      patch for a previous version if it's required
      1b3f124b
  27. 10 Feb, 2026 1 commit
  28. 06 Feb, 2026 1 commit