Populating Job summary with tests results and publish report

[TonioGela]

This should address #450, or at least begin to address it.
The content that will appear in the file can be discussed (and made fancier than the mere version number)
It's the first time I'm contributing to an sbt plugin, so I'm not sure if eventual IO (the sbt one's ofc :D) errors should be handled safely and more precisely logged for example.

[TonioGela]

😎

[TonioGela]

How about this @armanbilge?
I added a tlCiReleaseStepSummaryTableInfo setting and a render method. The table below was produced using these settings

ThisBuild / tlCiReleaseStepSummaryTableInfo += (
  "Scala Versions" -> crossScalaVersions.value.toString
)

[TonioGela]

I dedrafted the PR, since I implemented what me and @armanbilge discussed in these days. As it's possible to see in this CI run I embedded a test summary rendering in the TypelevelCiPlugin 👇

The TypelevelSonatypeCiReleasePlugin now exposes a setting called tlCiReleaseStepSummaryTableInfo that pilots the rendering of a "Build Results" table like this (w/o the "Job Summary" header):

by default it's value is

Map("**Release version**" -> (ThisBuild / version).value)

Now writing on the summary file is a noop if the variable is not defined and it appends to the file without overriding the content, meaning that every plugin can now decide to append other info to the summary if desired. Speaking of this, the "appending" functionality is now directly exposed by the GitHubActionsPlugin, since it's required by almost all the other ones.

  def appendtoStepSummary(summaryText: String) =
    Option(System.getenv("GITHUB_STEP_SUMMARY")).map { summaryFile =>
      IO.write(new File(summaryFile), summaryText, append = true)
    }

[TonioGela]

Also, I still haven't added any documentation since features might be reworked according to PR feedback but I will do once the PR will be considered ready ofc

[armanbilge]

Overall looks great! Just a few thoughts :)

[TonioGela]

@armanbilge I tried this impl to get the resolver URL just in the cases the resolver is a maven repo with a URL, but it should be definitively tested, as with publishLocal the publishTo doesn't get populated

[TonioGela]

For the moment these settings are producing a bunch of tables like 👇

sbt-typelevel-github-actions Publication Summary

Build Result	Value
Release version	0.4.18-24-5fe499e-20230205T100148Z-SNAPSHOT
Api URL	https://oss.sonatype.org/service/local/repositories/snapshots/archive/org/typelevel/sbt-typelevel-docs_2.12/0.4.18-24-5fe499e-20230205T100148Z-SNAPSHOT/sbt-typelevel-docs_2.12-0.4.18-24-5fe499e-20230205T100148Z-SNAPSHOT-javadoc.jar/!/index.html
Scala Versions	2.12.17

[armanbilge]

as with publishLocal the publishTo doesn't get populated

I mean, that's fine, since running publishLocal in CI doesn't put it anywhere you can use it anyway :)

I am also pretty sure it won't work on tagged releases which go to maven central. But that's also fine because everybody knows where to find those.

It's the snapshots that seem to have a lot of confusion, and this works perfectly for those.

[TonioGela]

as with publishLocal the publishTo doesn't get populated

I mean, that's fine, since running publishLocal in CI doesn't put it anywhere you can use it anyway :)

Not sure I follow. What I meant is that "on my laptop" the publishing fails before the command completes, and the only thing I had the chance to test is publishLocal overridden in the same way this publish is. To REALLY test with publish we should... well... publish :D

I am also pretty sure it won't work on tagged releases which go to maven central. But that's also fine because everybody knows where to find those.

Hmm, where's the configuration for tagged releases? I might take a look to try to make it compatible.

[armanbilge]

Hmm, where's the configuration for tagged releases? I might take a look to try to make it compatible.

Somewhere in https://github.com/xerial/sbt-sonatype

The reason I suspect it won't work is because sbt-sonatype does a "bundle release" when deploying to maven. So instead of setting publishTo to a sonatype resolver, IIUC it sets publishTo to your local file system, and then atomically uploads that as a bundle to Sonatype.

Anyway, I wouldn't worry about it. We can land this, and futz with that in a follow-up :)

[TonioGela]

Anyway, I wouldn't worry about it. We can land this, and futz with that in a follow-up :)

Sounds good, we can handle these improvements atomically. Also, I saw that there are a bunch of enhancement proposals for this plugin that might deserve some attention now that the shade curtain between me and sbt plugins is getting thinner :D

I don't think I have nothing else to develop in this PR, I'll wait for the definitive review.

[armanbilge]

Nice job with the resolver stuff!

One last round of thoughts, this is where I start sweating nervously about compatibility guarantees 😅 basically lets think hard about what we want to expose yet—the less we expose, the more opportunity we have to iterate on this without breaking anyone.

[armanbilge]

as with publishLocal the publishTo doesn't get populated

I mean, that's fine, since running publishLocal in CI doesn't put it anywhere you can use it anyway :)

I am also pretty sure it won't work on tagged releases which go to maven central. But that's also fine because everybody knows where to find those.

It's the snapshots that seem to have a lot of confusion, and this works perfectly for those.

[armanbilge]

Huh, what changed that causes us to need this now? Edit: oh sorry, you removed it in the next commit :)

[armanbilge]

Aight it's go time 😃

Update: https://github.com/typelevel/sbt-typelevel/actions/runs/4141308116/attempts/1#summary-11245005824 😎

Ok the *** thing is annoying, because we switched the org to s01.oss.sonatype.org via a secret, so GH is helpfully ***ing that 🤔

[TonioGela]

🎉 🎉 🎉 I'm so glad we merged it :)