compatible(build_charm.yaml): add CHARMCRAFT_EXPERIMENTAL_MONOREPO support

[imanenami]

charmcraft on latest/edge supports monorepo builds based on ST178 spec, this PR adds monorepo build support to build_charm.yaml by adding a monorepo boolean input variable, defaulting to false.

Sample experimental run: https://github.com/canonical/kafka-operator/actions/runs/34811463177/job/103935651559?pr=586

[carlcsaposs-canonical]

thank you for the PR!

I'd like to wait until it hits candidate or stable, when I tested it I saw an issue that I reported to Alex

also, we should remove charmcraftlocal at the same time, to avoid conflicts there (and charmcraftlocal will be deprecated as soon as the functionality is available in candidate/stable charmcraft)

ideally I'd like to enable this for all of our charms & not have any workflow input, as long as it doesn't cause regressions for charm builds without a local package

[imanenami]

also, we should remove charmcraftlocal at the same time, to avoid conflicts there (and charmcraftlocal will be deprecated as soon as the functionality is available in candidate/stable charmcraft)

ideally I'd like to enable this for all of our charms & not have any workflow input, as long as it doesn't cause regressions for charm builds without a local package

I believe even after a stable release from charmcraft, there will be a certain "transition" period when we need to keep both charmcraftlocal and the new feature of charmcraft, therefore I still think we need to support this in DPW as early as possible, otherwise the charms that adopted the git build root build up on parallel solutions which is not desirable imo.

[marcoppenheimer]

I'd like to wait until it hits candidate or stable, when I tested it I saw an issue that I reported to Alex

What was the issue?

[carlcsaposs-canonical]

"transition" period when we need to keep both charmcraftlocal and the new feature of charmcraft

I think they interfere with each other—i.e. I don't think it makes sense to have both enabled at once

in DPW as early as possible

charmcraft edge is subject to frequent "breaking" changes & historically has had significant "breaking" changes (not actually breaking since edge means they're not part of the stable api) for new features like this

even though experimental means it will still be subject to breaking changes in stable, would like to wait until it's a bit further than bleeding edge (to reduce breaking changes in dpw)

[carlcsaposs-canonical]

What was the issue?

log1.txt

log2.txt

wasn't sure if it was a bug or if I was doing something wrong, so was waiting to hear back from @lengau before opening a bug report. but haven't heard back, so perhaps worth opening a bug report

(the Aug 25 attempt was using the docs from this PR canonical/charmcraft#2844)