feat: restructure repository#40
feat: restructure repository#40akihikokuroda wants to merge 34 commits intogenerative-computing:mainfrom
Conversation
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>
Merge ProtectionsYour pull request matches the following merge protections and will not be merged until they are valid. 🟢 Enforce conventional commitWonderful, this rule succeeded.Make sure that we follow https://www.conventionalcommits.org/en/v1.0.0/
|
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>
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>
jakelorocco
left a comment
There was a problem hiding this comment.
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.
|
@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>
|
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: |
There was a problem hiding this comment.
this would need to be run manually right? would this be more for auditing or do you see another purpose?
There was a problem hiding this comment.
Yes, this must be run manually. I just left it for convenience. It can be deleted.
| push: | ||
| branches: | ||
| - main | ||
| paths: |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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", |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
I only flagged one, but there are multiple places we may need to update if we do want to bump
There was a problem hiding this comment.
Some tests failed with 0.4.0. Bumping 0.4.0 will be follow up PR.
psschwei
left a comment
There was a problem hiding this comment.
I think I am largely good with the changes here. would be good to have a review from the core team as well
fix #38