Add minimal CI workflows

[eazyhozy]

Summary

This PR introduces a minimal GitHub Actions CI workflow to ensure stable and repeatable merges in the early stage of the open-source project.

Result (edited)

Based on feedback in #11 (comment), the actions/labeler scripts were removed.

This PR includes only:

• CI (build) workflow
• Gradle cache configuration

Referrer

• actions/labeler
  • used by apache/spark
• dosubot
  • used by slatedb/slatedb

[eazyhozy]

@dosu Can you review this PR?

[dosubot]

Here's what I found: the only CI workflow currently in the repository is for website deployment via GitHub Pages, which runs build steps for the website but does not cover general build, test, lint, or labeler automation for the main codebase. The minimal CI pipeline (build, test, lint) is explicitly listed as a required task for the initial open-source release, and the project plans to use actions/labeler for short-term labeling automation, with a long-term goal of adopting AI-native tools like DosuBot for richer automation and PR feedback.

If this PR adds a minimal CI workflow with build, test, and labeler steps as described, it aligns well with both the project's roadmap and best practices seen in projects like Apache Spark and slatedb/slatedb. I recommend confirming that the workflow includes at least: a build job for the main codebase, a test job (even if minimal), linting (if applicable), and a labeler configuration. This will ensure stable, repeatable merges and help with early contributor onboarding. If any of these are missing, consider adding them to match the project's stated goals and community standards.

References:

• Open-source preparation and CI goals
• Current CI workflow (website deployment only)
• Labeling automation strategy

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

  

[eazyhozy]

@dosu Can you add labels to this PR?

[dosubot]

There isn’t an automated labeler or label configuration set up in this repo yet, so labels need to be added manually. For this PR, which introduces a minimal CI workflow, I recommend using standard labels like ci, github-actions, and workflow. These are common for changes related to continuous integration and GitHub Actions setup. If you want to establish a convention, these would be a good starting point.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

  

[em3s]

From a brief offline discussion between @em3s and @eazyhozy, we are sharing a short summary here for transparency.

Current state

• @dosu is currently used to automatically add labels when Issues or PRs are opened.
• Labels are selected from existing GitHub labels, and the specific set used by Dosu is configured in the Dosu app (https://app.dosu.dev).
• All Contributors can mention @dosu in Issues or PRs to interact with it (e.g. reviews, Q&A, summaries).

Plan and direction

• At the moment, Dosu is connected via a personal account on the free plan.
• We are considering moving to a paid plan through the internal software purchase process (supported by Kakao Corp.) if this setup continues to be useful.
• This is not a fixed decision. We will keep evaluating whether this approach works well for the community, and we are open to improving or adjusting our tooling as the project evolves.

[em3s]

Please remove the rule-based labeler from this PR and keep the scope focused on the minimal CI setup.

@eazyhozy

[eazyhozy]

@em3s
Thanks for the review. The rule-based labeler has been removed and the PR is now focused on the minimal CI setup (e5d47c2).

This PR enables Gradle build cache via org.gradle.caching=true.

Please review whether this is appropriate as a default setting for the project, and let me know if there are any concerns regarding cache safety or CI behavior.

[eazyhozy]

@dosu please update your previous review #11 (comment).

[dosubot]

The PR now focuses only on a minimal CI workflow with Gradle cache enabled, and the rule-based labeler scripts have been removed as requested. Enabling org.gradle.caching=true in CI is generally a good default for early-stage projects: it speeds up builds and helps ensure repeatability. However, it's important to watch for potential issues like non-deterministic tasks, cache poisoning, or sensitive artifacts being cached. To minimize risk, use unique cache keys, avoid caching outputs from non-deterministic steps, and monitor cache usage in build logs. Regularly reviewing CI performance and correctness as the project evolves is recommended. Once merged, a follow-up review can help catch any project-specific issues with the cache or workflow setup.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

  

[em3s]

LGTM 👍

I checked the workflow run:
https://github.com/kakao/actionbase/actions/runs/20767979252

Everything works as expected. The PR is well-scoped to a minimal CI setup.

[em3s]

I’ve already approved this PR 👍

Before merging, could you please make a small adjustment to align with the intended CI scope?

• Only PRs targeting main
• Exclude draft PRs
• Cover direct pushes to main

A possible configuration would be:

on:
  push:
    branches: [ main ]

  pull_request:
    branches: [ main ]
    types:
      - opened
      - reopened
      - synchronize
      - ready_for_review

@eazyhozy

[eazyhozy]

@em3s

Thanks for the suggestion.
I’ve updated the CI config to match the intended scope:

on:
  push:
    branches: [ main ]

  pull_request:
    branches: [ main ]
    types:
      - opened
      - reopened
      - synchronize
      - ready_for_review

jobs:
  build:
    if: >
      github.event_name == 'push' ||
      (github.event_name == 'pull_request' && github.event.pull_request.draft == false)

[em3s]

LGTM 👍