Add GitHub action to publish Kdocs

[martinbonnin]

No description provided.

[SimonMarquis]

@martinbonnin the KDocs contains internal packages, is this on purpose?
I tried to search for the dokkatoo config but did not found it. Is it included by librarian?

[martinbonnin]

the KDocs contains internal packages, is this on purpose?

@SimonMarquis I won't say it's on purpose but I'm not 100% clear how much of the symbols used by Gradle can be internal (extensions, tasks). Since Gradle extends them and does some magic to "hydrate them". All the tasks are abstract classes so feels like they are "public" for the Gradle runtime but "private" for the end user. The way I'm currently modelling this is by using this internal package...

Maybe everything can be Kotlin internal. Probably that won't prevent Java callers like the Gradle runtime to access them, I'll try.

[SimonMarquis]

Gradle being written in Java does not have the concept of internal. So I'm pretty confident it does not matter for Gradle.

• internal abstract works
  https://github.com/SimonMarquis/Android-Playground/blob/93ecd9216903c6b10c9e8e5dec9f432021572788/build-logic/src/main/kotlin/fr/smarquis/playground/buildlogic/utils/PlaygroundBadging.kt#L103
• so does private abstract 😄
  https://github.com/SimonMarquis/Android-Playground/blob/93ecd9216903c6b10c9e8e5dec9f432021572788/build-logic/src/main/kotlin/fr/smarquis/playground/buildlogic/utils/PlaygroundGraph.kt#L109

[martinbonnin]

private abstract sounds interesting 👀

Follow up PR there: #138

[martinbonnin]

@SimonMarquis On this topic, do you have any idea how to track configuration/task names?

The values of these symbols are public API (not the symbols themselves) but I don't think there is a way to track this?

[SimonMarquis]

Do you mean publishAggregationToCentralPortal, publishAggregationToCentralPortalSnapshots, nmcpAggregation etc?
Could they just be extracted as static top level variables?

[martinbonnin]

Do you mean publishAggregationToCentralPortal, publishAggregationToCentralPortalSnapshots, nmcpAggregation etc?

Yes

Could they just be extracted as static top level variables?

Yes, but BCV will only track the presence of the symbol, not its value. If one day the symbol gets changed to:

-val taskName = "publishAggregationToCentralPortal"
+val taskName = "publishToCentralPortal"

Then it's breaking everyone's script but that will not be noticed by BCV

I tried to search for the dokkatoo config but did not found it. Is it included by librarian?

Sorry forgot to answer this but yes, it it. It is all happening here.

Tweaking the dokkatoo config is one option but my preference would go to hiding them in the first place instead of duplicating some logic.

[SimonMarquis]

I can see at least 23 solutions to avoid breaking consumers:

• adding unit tests that ensures the task names are as expected
• adding integration tests (Gradle Test Kit) that ensures the tasks exists
• making top level data objects whose name can then be used at runtime (that would be tracked by BCV)

  public data object publishAggregationToCentralPortal
  
  tasks.register(publishAggregationToCentralPortal.toString()) { }

[martinbonnin]

making top level data objects whose name can then be used at runtime (that would be tracked by BCV)

I can't make my mind whether this is a genious or very terrible idea 😄

I guess I'll stick with tests, testing behaviour is indeed what they are for! Thanks!