Skip to content

feat: restructure repository#40

Open
akihikokuroda wants to merge 34 commits intogenerative-computing:mainfrom
akihikokuroda:reporestructure
Open

feat: restructure repository#40
akihikokuroda wants to merge 34 commits intogenerative-computing:mainfrom
akihikokuroda:reporestructure

Conversation

@akihikokuroda
Copy link
Member

fix #38

Signed-off-by: Akihiko Kuroda <akihikokuroda2020@gmail.com>
Signed-off-by: Akihiko Kuroda <akihikokuroda2020@gmail.com>
Signed-off-by: Akihiko Kuroda <akihikokuroda2020@gmail.com>
Signed-off-by: Akihiko Kuroda <akihikokuroda2020@gmail.com>
Signed-off-by: Akihiko Kuroda <akihikokuroda2020@gmail.com>
Signed-off-by: Akihiko Kuroda <akihikokuroda2020@gmail.com>
Signed-off-by: Akihiko Kuroda <akihikokuroda2020@gmail.com>
@akihikokuroda akihikokuroda marked this pull request as draft March 18, 2026 19:01
@mergify
Copy link

mergify bot commented Mar 18, 2026

Merge Protections

Your pull request matches the following merge protections and will not be merged until they are valid.

🟢 Enforce conventional commit

Wonderful, this rule succeeded.

Make sure that we follow https://www.conventionalcommits.org/en/v1.0.0/

  • title ~= ^(fix|feat|docs|style|refactor|perf|test|build|ci|chore|revert|release)(?:\(.+\))?:

Signed-off-by: Akihiko Kuroda <akihikokuroda2020@gmail.com>
Signed-off-by: Akihiko Kuroda <akihikokuroda2020@gmail.com>
Signed-off-by: Akihiko Kuroda <akihikokuroda2020@gmail.com>
Signed-off-by: Akihiko Kuroda <akihikokuroda2020@gmail.com>
Signed-off-by: Akihiko Kuroda <akihikokuroda2020@gmail.com>
Signed-off-by: Akihiko Kuroda <akihikokuroda2020@gmail.com>
Signed-off-by: Akihiko Kuroda <akihikokuroda2020@gmail.com>
Signed-off-by: Akihiko Kuroda <akihikokuroda2020@gmail.com>
Signed-off-by: Akihiko Kuroda <akihikokuroda2020@gmail.com>
Signed-off-by: Akihiko Kuroda <akihikokuroda2020@gmail.com>
Signed-off-by: Akihiko Kuroda <akihikokuroda2020@gmail.com>
Signed-off-by: Akihiko Kuroda <akihikokuroda2020@gmail.com>
Signed-off-by: Akihiko Kuroda <akihikokuroda2020@gmail.com>
Signed-off-by: Akihiko Kuroda <akihikokuroda2020@gmail.com>
Signed-off-by: Akihiko Kuroda <akihikokuroda2020@gmail.com>
Signed-off-by: Akihiko Kuroda <akihikokuroda2020@gmail.com>
Signed-off-by: Akihiko Kuroda <akihikokuroda2020@gmail.com>
Signed-off-by: Akihiko Kuroda <akihikokuroda2020@gmail.com>
Signed-off-by: Akihiko Kuroda <akihikokuroda2020@gmail.com>
Signed-off-by: Akihiko Kuroda <akihikokuroda2020@gmail.com>
akihikokuroda and others added 5 commits March 19, 2026 14:08
Signed-off-by: Akihiko Kuroda <akihikokuroda2020@gmail.com>
Signed-off-by: Akihiko Kuroda <akihikokuroda2020@gmail.com>
Add detect-changes job that checks which subpackages have been modified and outputs flags for each. Each subpackage workflow now only runs when:
- Its files in mellea_contribs/ are changed, OR
- Its corresponding quality workflow file is changed

This prevents unnecessary CI runs when only unrelated subpackages are modified.

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Signed-off-by: Akihiko Kuroda <akihikokuroda2020@gmail.com>
Signed-off-by: Akihiko Kuroda <akihikokuroda2020@gmail.com>
@akihikokuroda akihikokuroda marked this pull request as ready for review March 19, 2026 20:38
Copy link

@jakelorocco jakelorocco left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible to make the workflows dynamic? Ie instead of having to create a new one for each subpackage, we just mandate all folders under mellea_contribs are subpackages and require some sort of structure?

Even if we don't have that, we should make sure to have a version of the quality check that ensures new packages have tests. For example, if I make a new subpackage and don't add tests / quality workflows right now, will I be able to merge? Or there's some necessary check still?

I'm also not certain how these differently named checks interact with github branch protections? For the mellea repo, we have to specifically select checks.

@akihikokuroda
Copy link
Member Author

@jakelorocco A new CI that checks if each subpackage has its own ci can be added. The quality of each ci is up-to the subpackage though. Is it enough as a minimum?

@jakelorocco
Copy link

@jakelorocco A new CI that checks if each subpackage has its own ci can be added. The quality of each ci is up-to the subpackage though. Is it enough as a minimum?

I think that makes sense. We should vet CI at merge time, but a check will ensure nothing gets through accidentally.

Signed-off-by: Akihiko Kuroda <akihikokuroda2020@gmail.com>
@psschwei
Copy link
Member

Once this merges, we'll also need to update the required checks in the branch protections ( as the quality checks no longer exist)

on:
pull_request:
types: [opened, reopened, synchronize]
workflow_dispatch:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this would need to be run manually right? would this be more for auditing or do you see another purpose?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this must be run manually. I just left it for convenience. It can be deleted.

push:
branches:
- main
paths:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

since all the backends depend on mellea-integration-core, there is the chance that if we change something in the core that it would break the backends... should we also trigger a run of the backends if the core changes?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's right. I'll add mellea-integration-core change in all integration paths.

Signed-off-by: Akihiko Kuroda <akihikokuroda2020@gmail.com>

dependencies = [
"mellea>=0.3.2",
"mellea==0.3.2",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we want to bump this to 0.4.0?
longer-term, we probably need to sync our update strategy here to the release process
cc @jakelorocco

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I only flagged one, but there are multiple places we may need to update if we do want to bump

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some tests failed with 0.4.0. Bumping 0.4.0 will be follow up PR.

Copy link
Member

@psschwei psschwei left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I am largely good with the changes here. would be good to have a review from the core team as well

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

feat: refactor to multi package

3 participants