typelevel / sbt-typelevel Goto Github PK

View Code? Open in Web Editor NEW

165.0 15.0 47.0 2.11 MB

Let sbt work for you.

Home Page: https://typelevel.org/sbt-typelevel/

License: Apache License 2.0

Scala 100.00%

scala sbt-plugin typelevel sbt

sbt-typelevel's Introduction

sbt-typelevel

sbt-typelevel configures sbt for developing, testing, cross-building, publishing, and documenting your Scala library on GitHub, with a focus on semantic versioning and binary compatibility. It is a collection of plugins that work well individually and even better together.

Features

Auto-generated GitHub actions workflows, parallelized on Scala version and platform (JVM, JS, Native)
git-based dynamic versioning
Binary-compatibility checking with MiMa, following early semantic versioning
CI publishing of releases and snapshots to Sonatype/Maven
CI deployed GitHub pages websites generated with mdoc and Laika
Auto-populated settings for various boilerplate (SCM info, API doc urls, Scala.js sourcemaps, etc.)

Get Started

sbt new typelevel/typelevel.g8

Visit https://typelevel.org/sbt-typelevel for a quick start example and detailed documentation. Find the Giter8 template companion project at typelevel.g8.

Contributors ✨

Thanks goes to these wonderful people (emoji key):

₁₁₀₄₁₆ 🔬	_{Akinmolayan Olushola} 💻	_{Amund Murstad} 💻	_{Andrew Valencik} 💻 📖 🔧	_{Antonio Gelameris} 💻 👀	_{Arman Bilge} 💻 👀 📖	_{Ben Plommer} 💻
_{Brian P. Holt} 💻 🤔 🔧	_{Christopher Davenport} 💻	_{Daniel Esik} 💻 📖	_{Daniel Spiewak} 💻	_{Daniel Urban} 🐛	_{David Gregory} 💻 👀	_{David Strawn} 📖
_{Eric Meisel} 🐛 💻	_{Jamie Willis} 💻 🎨	_{Jens Halm} 💻 📖 👀	_{Justin Reardon} 🔬	_{Lucas Satabin} 🐛 💻	_{Maksym Ochenashko} 💻	_{Marco Zühlke} 💻 📖 👀
_{Michel Davit} 💻	_{PJ Fanning} 💻	_{Ross A. Baker} 💻 🤔 👀	_{Sam Pillsworth} 🤔 👀	_{Sergey Torgashov} 💻 👀	_{Simon Parten} 📖	_{Vasil Vasilev} 💻 🤔
_zetashift 💻

This project follows the all-contributors specification. Contributions of any kind welcome!

sbt-typelevel's People

Contributors

Stargazers

Watchers

Forkers

olegych armanbilge scala-steward akilegaspi isomarcte osleonard danicheg rossabaker quafadas sh0hei opencastsoftware valencik djspiewak pjfanning irevive satorg dwolla vasilmkd bplommer eternalerrors jenshalm softinio zetashift hnaderi reardonj librecybernetics j-mie6 mdedetrich dragonfly-ai etspaceman amumurst doehla mzuehlke diogocanut durban austinwarrren rustedbones hegoriaqirelle rosellow baldogarasd uraniqbremto satabin som-snytt kubukoz zarthross majk-p

sbt-typelevel's Issues

Fail if tag is older than base version

As long as you have binary-breaking changes on a branch, then tagging a non-breaking version number will fail the bincompat checks.

However, currently in sbt-typelevel the series/0.4 branch and main (base version 0.5) are actually binary-compatible, but semantically incompatible. So accidentally tagging 0.4.x on main would succeed in publishing, which is not what we want.

generated workflow has wrong publish command

sbt-typelevel/.github/workflows/ci.yml

Lines 132 to 133 in f8f808f

    
                 - name: Publish project 
        
                   run: sbt ++${{ matrix.scala }} +publish

Should be release instead of +publish. This is a regression, will track it down. Also, we need tests 😅

Support CI matrices split across JVM/JS

By default sbt-gh-actions generates a separate job for each scala/java version. However, many projects also have separate jobs for JVM/JS. Some thoughts:

Should we do this by default? Personally I like it because it's not always easy to tell from combined jobs whether a test failure occurred in JVM or JS if they are running the same tests. However, it increases the build matrix by 3 jobs, each which has some constant overhead. The decrease in CI time definitely worth for larger projects, but not so much for smaller ones.
To do this properly needs more support from sbt-gh-actions, which I think doesn't distinguish between caches for JVM/JS and thus they end up overriding each other. Also might be complicated to implement.
I tried to set this up once and ran into problems with CI release, I think related to the caching thing in (2). So it should be checked if that works (I volunteer bobcats for this).

Linking to #18 b/c trying to upstream this change to sbt-gh-actions might take longer than absorbing it 🙃

Relative version not set correctly

The plugin does not recognise and set the next relative version correctly:

$ sbt release
[...]
[info] Current version is: 0.1.2-SNAPSHOT
Release (relative) version: 2
Next release series [0.1]: 0.1
[info] Bumping release series to 0.1, setting next relative version to 0-SNAPSHOT
[info] Setting version to 0.1.2
[info] Reapplying settings...
[info] Set current project to widok (in build file:/Users/tim/dev/widok/)
[info] [master b0e0509] Setting version to 0.1.2
[info]  1 file changed, 1 insertion(+), 1 deletion(-)
[info] Reapplying settings...
[info] Set current project to widok (in build file:/Users/tim/dev/widok/)
[info] Reapplying settings...
[info] Set current project to widok (in build file:/Users/tim/dev/widok/)
[info] Updating {file:/Users/tim/dev/widok/}widok...
[info] Packaging /Users/tim/dev/widok/target/scala-2.11/widok_sjs0.5_2.11-0.1.2-sources.jar ...
[info] Done packaging.
[info] Resolving org.scala-lang.modules#scala-xml_2.11;1.0.1 ...
[info] Done updating.
[info] Wrote /Users/tim/dev/widok/target/scala-2.11/widok_sjs0.5_2.11-0.1.2.pom
[info] :: delivering :: io.github.widok#widok_sjs0.5_2.11;0.1.2 :: 0.1.2 :: release :: Mon Oct 27 18:35:52 GMT 2014
[info]  delivering ivy file to /Users/tim/dev/widok/target/scala-2.11/ivy-0.1.2.xml
[info] Main Scala API documentation to /Users/tim/dev/widok/target/scala-2.11/api...
[info] Packaging /Users/tim/dev/widok/target/scala-2.11/widok_sjs0.5_2.11-0.1.2.jar ...
[info] Done packaging.
[warn] there were 16 feature warnings; re-run with -feature for details
model contains 225 documentable templates
[warn] one warning found
[info] Main Scala API documentation successful.
[info] Packaging /Users/tim/dev/widok/target/scala-2.11/widok_sjs0.5_2.11-0.1.2-javadoc.jar ...
[info] Done packaging.
Please enter PGP passphrase (or ENTER to abort): ************
[info]  published widok_sjs0.5_2.11 to https://oss.sonatype.org/service/local/staging/deploy/maven2/io/github/widok/widok_sjs0.5_2.11/0.1.2/widok_sjs0.5_2.11-0.1.2-sources.jar
[info]  published widok_sjs0.5_2.11 to https://oss.sonatype.org/service/local/staging/deploy/maven2/io/github/widok/widok_sjs0.5_2.11/0.1.2/widok_sjs0.5_2.11-0.1.2.jar
[info]  published widok_sjs0.5_2.11 to https://oss.sonatype.org/service/local/staging/deploy/maven2/io/github/widok/widok_sjs0.5_2.11/0.1.2/widok_sjs0.5_2.11-0.1.2.pom.asc
[info]  published widok_sjs0.5_2.11 to https://oss.sonatype.org/service/local/staging/deploy/maven2/io/github/widok/widok_sjs0.5_2.11/0.1.2/widok_sjs0.5_2.11-0.1.2.pom
[info]  published widok_sjs0.5_2.11 to https://oss.sonatype.org/service/local/staging/deploy/maven2/io/github/widok/widok_sjs0.5_2.11/0.1.2/widok_sjs0.5_2.11-0.1.2-javadoc.jar.asc
[info]  published widok_sjs0.5_2.11 to https://oss.sonatype.org/service/local/staging/deploy/maven2/io/github/widok/widok_sjs0.5_2.11/0.1.2/widok_sjs0.5_2.11-0.1.2-javadoc.jar
[info]  published widok_sjs0.5_2.11 to https://oss.sonatype.org/service/local/staging/deploy/maven2/io/github/widok/widok_sjs0.5_2.11/0.1.2/widok_sjs0.5_2.11-0.1.2-sources.jar.asc
[info]  published widok_sjs0.5_2.11 to https://oss.sonatype.org/service/local/staging/deploy/maven2/io/github/widok/widok_sjs0.5_2.11/0.1.2/widok_sjs0.5_2.11-0.1.2.jar.asc
[success] Total time: 140 s, completed 2014-10-27 18:38:11
[info] Setting version to 0.1.0-SNAPSHOT
[info] Reapplying settings...
[info] Set current project to widok (in build file:/Users/tim/dev/widok/)
[info] Unstable branch; not setting `lastRelease`
[info] [master db4e76c] Setting version to 0.1.0-SNAPSHOT
[info]  1 file changed, 1 insertion(+), 1 deletion(-)

It should not set the version to 0.1.0-SNAPSHOT, but 0.1.3-SNAPSHOT. I am also puzzled why sbt-typelevel thinks that the branch is unstable.

typelevel.g8

Spinning out of #16 (comment).

Project verification job

Half-baked idea:

*githubWorkflowCheck runs everywhere, but doesn't vary by JVM or Scala version

This is also true of scalafmtSbtCheck.
It would also be true of prospective validation of scala-steward.conf

Should there be a project job for the project-level verifications, so they're run only once? They aren't that slow, so it's not a priority, but getting these wrong fails lots of jobs right now.

Is artifact upload necessary for PRs?

This was a default inherited from sbt-gh-actions/sbt-spiewak, but as pointed out in typelevel/shapeless-3#63 (comment) it seems unnecessary for PRs. If it's not, we can add a conditional to skip it for PRs.

Rename `master` -> `main`

incompatible with sbt 0.13.8

sbt-typelevel : 0.3.1
sbt.version: 0.13.8

> checkDependencies
[info] Updating {file:/Users/markusklink/Projects/scala/play-spray2json/}play-spray2json...
[info] Resolving jline#jline;2.12.1 ...
[info] Done updating.
[trace] Stack trace suppressed: run last compile:ivyReport for the full output.
[error] (compile:ivyReport) java.lang.IllegalStateException: sbt-dependency-graph plugin currently only supports InlineConfiguration of ivy settings (the default in sbt)

Downgrading to 0.13.7 solves the problem. This is probably due to sbt/sbt-dependency-graph#67

Should a docs step be part of the default CI?

Alongside the current defaults mimaReportBinaryIssues and test.

http4s uses it, Rob uses it, possibly some other projects I will find out about.

More maintainers/contributors?

I'd appreciate more hands on deck especially as we try and get lift-off on this :) I marked some issues as help-wanted.

Missing scalac flags on 2.12

As compared with sbt-spiewak: -Ypartial-unification and -Ybackend-parallelism N

Came up in http4s/http4s-dom#77.

SPDX headers?

I have swallowed a bunch of defaults I don't like in the interest of comity, but typelevel/jawn#402 has me wondering about whether this is our opportunity to wave the flag for SPDX. It accomplishes the same, is more terse, and is machine readable. SPDX is good.

Add JDK target setting

This one is inspired by @ahjohannessen in armanbilge/fs2-grpc#1 (comment).

It would default to JDK 8, of course :) We could just hardcode this, but I think it would be nice if our settings plugin is friendly to applications that know they will be running on a newer JVM.

Push-and-tag still has a race condition

This just happened in typelevel/fs2-grpc#478. cc @ahjohannessen.

Even though the CI job for the push (not the tag) ignores the tag on HEAD for purposes of versioning, it still sees the tag as a previous version when checking binary compatibility, and gets into trouble since it has not been published yet.

Move `org.typelevel` to `s01.oss.sonatype.org`

Wanted to document more permanently @bpholt's excellent suggestion. This is currently the recommendation at https://status.maven.org/:

Investigating - Staging operations continue to run slow, and the current load on oss.sonatype.org isn't decreasing any time soon (which would allow the backlog to clear up). Please consider migrating to our new, much less loaded host. See here for context: https://twitter.com/sonatype_ops/status/1471099908300189705

Note that this will require changing the publish config for all typelevel projects to the new host (the change is completely transparent to dependencies using the artifacts i.e. no need to add additional resolvers).

sonatypeCredentialHost := "s01.oss.sonatype.org"

@tpolecat documented how to make this change on Twitter.

Example build with this config (note all the places it is set):
https://github.com/armanbilge/schrodinger/blob/0897f5a07c5f02fd00b20c171590812906e16984/build.sbt

tlVersionIntroduced as a function of scalaVersion

Modules get introduced in different versions for different crossbuilds. sbt-spiewak takes a function of Scala versions to version introduced:

    versionIntroduced := Map(
      "3.0.0-RC1" -> "1.0.0",
      "3.0.0-RC2" -> "1.0.1",
      "3.0.0-RC3" -> "1.1.3"
    ),

I'm not sure how we express that in tlVersionIntroduced.

Make artifact upload/download step cross-aware

For matrices with independent jobs for JVM/JS, both jobs are uploading their artifacts under the same name. So when the publish job downloads these artifacts, it is only getting half, and has to recompile the other half during the release step.

Optional microsite plugin

It doesn't have to be for everyone and it doesn't have to be too fancy. Just something easy.

I had an excellent experience with laika in http4s/http4s-dom#29. There's a lot of boilerplate config in there I think that an opinionated plugin can make go away. The other magic is the peaceiris action for publishing to gh-pages. For a simple microsite, it really just works.

Another contender is the new site-generating capabilities in Scaladoc 3, but I haven't experimented with those.

Versioned documentation

It would be nice to have a turnkey solution for projects that wish to support versioned documentation.

Requirements

Table stakes

Each maintained branch gets its own set of docs
Can publish from maintenance branches without breaking new things
Can publish from main without breaking old things

Nice to have

A new version updates the version selector in old versions
EOL versions can easily point to a maintained version
Version selector jumps to corresponding page, or a fallback if not relevant. (Laika does this.)
If a PR will break the site generator, it fails. (A risk if mdoc compilation is separate from site generation.)

Extra credit

/stable/* redirects to the latest stable version, like Read The Docs. This was possible on Netlify, which is an administrative headache. This is impossible on gh-pages.
Works across repos for polyrepo projects (subdomains are a viable alternative)
EOL versions are not indexed by Google. (Maybe. This would improve SEO within the site, but could hurt it to the site.)

Prior art

http4s

The /docs directory on live branches publishes to a subdirectory of the gh-pages branch. The /website directory is published off main and contains the project information that pertains to all branches.

Because each branch publishes independently, there is no way to update the theme across the board, nor a way to automatically update the version selector on old branches when release statuses change. Care must be taken to not touch anything outside that subdirectory.

cats-effect

I don't know how it works. Submodules and stuff. Generates crufty PRs, but the end user experience is best-in-Typelevel.

Monix

Has also been doing it for years in an artisanal fashion.

Other Scala projects that do a nice job and are worth studying

Akka
Play

Other tooling

Laika has multiple version support, and sbt-typelevel already integrates Laika

Other ideas

All of these are based on the idea that the site generator runs once, instead of independent sites per version and for the common area. This raises a basic tradeoff:

If the site generator runs in the CI of a branch, we have a race condition
If the site generator is triggered by a workflow after a branch is merged, that branch can break the site

Publish mdocs per branch, separate job generates the site

Requires careful git exclusions. Is the most economical with CI time.

mdoc all the branches and generate the site in one job

Awfully slow for large projects.

Parallelize building all branches, upload artifacts, generate in separate job

It's a heavy build, but it avoids git exclusions

Project URL and license information

I pushed my project to Sonatype and it was rejected with the following message:

Project URL missing, License information missing

In https://github.com/non/jawn/blob/master/project/Build.scala the variables homepage and licenses are set manually. If this is the proper way to configure sbt-typelevel, it should be indicated in the README.

Bring in sbt-gpg

https://github.com/jodersky/sbt-gpg

It's a critical plugin, a modest amount of sources, and the current bus factor is probably about 2. I say bring it in as sbt-typelevel-gpg.

A way to backpublish tags in CI?

Noticed this in typelevel/kind-projector#196.

Possibly too esoteric, and kind projector use-case will slowly sunset anyway.

Bring in sbt-github-actions

https://github.com/djspiewak/sbt-github-actions

Another important one, that IMHO could do with a bus-factor upgrade. This one is much larger though.

Shared scalafmt config?

Possibly a good idea, or a very bad one. But I am tired of copying variations of this file around my repos, and scalafmt updates change stuff all the time which means settings can get stale quickly.

This is a bit annoying to implement: it seems the correct way to do it would be to check-in a generated .scalafmt-common.conf (it would have to be managed/validated in CI like the ci.yml generated workflow).

Then every repo would have a .scalafmt.conf with the following contents:

include ".scalafmt-common.conf"

I believe this would give a repo the freedom to overwrite settings and/or completely ignore the common ones.

sbt-typelevel adoption

A super-issue to keep track of progress.

v0.4.0

https://github.com/typelevel/sbt-typelevel/milestone/1

This is more of a 0.1.0, except this is the next available version. In any case, what do we need to do to get here?

After the latest round of PRs merge I will probably migrate http4s-dom and feral.

todo

steward support, merged but may need to be released?
scala-steward-org/scala-steward#2443
bikeshed all the names. I'd love to make more stuff private, but I'm scared of sbt.
#80

ThisBuild / tlVersionIntroduced not taking effect

ThisBuild / tlVersionIntroduced does not seem to be working

Example: typelevel/case-insensitive@d8a042f

sbt:case-insensitive> inspect coreJVM/tlVersionIntroduced
[info] Setting: scala.collection.immutable.Map[java.lang.String, java.lang.String] = Map()
[info] Description:
[info] 	A map scalaBinaryVersion -> version e.g. Map('2.13' -> '1.5.2', '3' -> '1.7.1') used to indicate that a particular crossScalaVersions value was introduced in a given version (default: empty).
[info] Provided by:
[info] 	ProjectRef(uri("file:/Users/ross.baker/src/case-insensitive/"), "coreJVM") / tlVersionIntroduced
[info] Defined at:
[info] 	(org.typelevel.sbt.TypelevelMimaPlugin.projectSettings) TypelevelMimaPlugin.scala:40
[info] Reverse dependencies:
[info] 	coreJVM / mimaPreviousArtifacts
[info] Delegates:
[info] 	coreJVM / tlVersionIntroduced
[info] 	ThisBuild / tlVersionIntroduced
[info] 	Global / tlVersionIntroduced
[info] Related:
[info] 	testsJS / tlVersionIntroduced
[info] 	bench / tlVersionIntroduced
[info] 	testingJS / tlVersionIntroduced
[info] 	testingJVM / tlVersionIntroduced
[info] 	ThisBuild / tlVersionIntroduced
[info] 	site / tlVersionIntroduced
[info] 	testsJVM / tlVersionIntroduced
[info] 	tlVersionIntroduced
[info] 	coreJS / tlVersionIntroduced

Also does nothing from the sbt shell:

sbt:case-insensitive> set ThisBuild / tlVersionIntroduced := Map("3" -> "1.3.4")
[info] Defining ThisBuild / tlVersionIntroduced
[info] The new value will be used by no settings or tasks.
[info] Reapplying settings...
[info] set current project to case-insensitive (in build file:/Users/ross.baker/src/case-insensitive/)

Don't bring in new plugins and outsource some of the existing

Since I'm opening #17 and #18, it's only fair to consider the opposite argument. @ChristopherDavenport in particular encouraged that we delegate to his existing no-publish and mima plugins, and offered to donate them to typelevel org. sbt-tpolecat is another one we could outsource to instead of our own settings plugin.

My concerns with this are:

bus factor
try getting your head around how sbt-gh-actions is released by sbt-spiewak without a direct dependency :)

Warn in CI about passphrase-protected keys

This is automatically supported (via a workaround) to help migration, but I think we want to discourage it.

To force users to acknowledge this problem (and especially to prevent new users from making this mistake) we could require an opt-in sbt-setting to enable this legacy mode. But, some people might balk :)

We should also add docs explaining exactly how to install a key without a passphrase. I'm horrible and lazy, so I just make passphrase-less keys but I think you can also export a passphrased-key without the passphrase protection. Or #22 would help too.

Still have race-conditions / double-release problem for simultaneous push+tag push

This condition was supposed to prevent it:

sbt-typelevel/.github/workflows/ci.yml

Line 128 in ac41c6a

    
                 - if: (startsWith(github.ref, 'refs/tags/v') && github.ref_type == 'tag') || (!startsWith(github.ref, 'refs/tags/v') && github.ref_type != 'tag')

However, it seems that both github.ref and github.ref_type are defined by the ref that caused the workflow to start (makes sense in retrospect). So they will never be out-of-sync, which is precisely the indicator we rely on to determine if a push-triggered workflow is trying to do a proper tag release and stop it. So I need to rethink this.

Workflow for setting up signing keys in CI

This is one from @ChristopherDavenport :)

My idea of how it could work:

Currently, sbt-gh-actions generates a clean workflow and a CI workflow. It could also generate a third workflow, run by a "dispatch trigger" (i.e., you have to click a button and provide some inputs in web UI) that could:

generate a key

set it as a repo secret

send it to a key server

This would make it extremely easy.

#11 (reply in thread) for some discussion

Should the single `ci` command alias be split into multiple workflow steps?

Spinning out of http4s/sbt-http4s-org#120 (comment).

This is a pattern I adopted from sbt-spiewak, but it obviously has tradeoffs.

Pros:

a single command, that in theory you can run locally to emulate CI
works well when split into ciJVM, ciJS, etc.
doesn't have to restart sbt for each step

Cons:

harder to see on what step a build fails
difficult to progressively build up the commands in the alias, or remove stuff
sometimes, restarting sbt is actually a good thing

Turn the README into helpful documentation

At the very least:

how to get started with the super-plugins
how the baseVersion works
how to generate and install keys/creds
... anything else 🤔

`prePR` bot

Building on #15.

Assuming that we get our prePR command, I want a way to ask CI to run prePR for me and commit the changes.

I wonder if this can be accomplished (mostly) by spitting out an additional workflow. The only trick bit is figuring out how to conveniently trigger that workflow.

Re-organize top-level-plugins

Currently, the super-plugins are sbt-typelevel (which brings in everything but CI release) and sbt-typelevel-ci-release (which adds in CI release). This was following after sbt-spiewak, to accommodate projects that don't want to do CI releases.

Based on feedback from the Discord discussion yesterday, I think I got it wrong. My take-aways were that:

CI release is the real bottleneck/headache for almost everyone
besides that, many people don't want to be dictated scalac settings, etc.

However, there is also Ross's desire in #11 (reply in thread) for a plugin:

Shrinks the typical build.sbt (or extensions like sbt-http4s-org) to the point that updates to this plugin keep that build fresh.

So, my new proposal is:

sbt-typelevel-ci-release: a super-plugin including versioning+mima+signing+sonatype+ci-release, but no more.
sbt-typelevel: a super-super-plugin, that gets you all of the above, plus whatever else is needed to achieve Ross's vision, so scalac settings, even scalafmt, sbt-header, mdoc, what-have-you.

(2) will be very opinionated of course, but I think that's perfectly fine for many projects. Anyone who wants more fine-grained-control can always drop down to sbt-typelevel-ci-release and then build up their plugin/settings stack as they see fit.

sbt-header support?

One thing missing from sbt-spiewak is sbt-header support. Maybe that's out of scope, but it's the first migration roadblock I hit.

Versioning breaks when there is a current tag

This showed up while working on spire.

java.lang.RuntimeException: Version must be semver format: v0.18.0-M3
        at scala.sys.package$.error(package.scala:30)
        at org.typelevel.sbt.TypelevelMimaPlugin$.$anonfun$projectSettings$5(TypelevelMimaPlugin.scala:49)

There are two problems here:

0.18.0-M3 was released today, so is tagged on HEAD. Despite the dirty workspace, it is still using the tag value.
The version hasn't removed the "v" prefix from the tag.

TypelevelSitePlugin assumes site is in a directory called docs

https://github.com/typelevel/cats-uri/runs/4909193164?check_suite_focus=true#step:5:30

Fail silently on artifact upload/download steps?

These seem to flake occasionally and are not really critical, just shuffling caches to save recompilation during the release job. So it would probably be okay for them to fail silently.

An example in https://github.com/typelevel/jawn/runs/4859261390?check_suite_focus=true#step:14:1.

Run actions/upload-artifact@v2
With the provided path, there will be 1 file uploaded
Starting artifact upload
For more detailed logs during the artifact upload process, enable step-debugging: https://docs.github.com/actions/monitoring-and-troubleshooting-workflows/enabling-debug-logging#enabling-step-debug-logging
Artifact name is valid!
Container for artifact "target-ubuntu-latest-2.13.8-temurin@8" successfully created. Starting upload of file(s)
Uploaded /home/runner/work/jawn/jawn/targets.tar (81.2%) bytes 0:8388607
A 503 status code has been received, will attempt to retry the upload
Exponential backoff for retry #1. Waiting for 5499 milliseconds before continuing the upload at offset 8388608
Finished backoff for retry #1, continuing with upload
Error: Unexpected response. Unable to upload chunk to https://pipelines.actions.githubusercontent.com/dr4d5xdeYJVOyUhrZtz8KK0R6jc49DIbpbB6Fk82oUW560k70a/_apis/resources/Containers/12175527?itemPath=target-ubuntu-latest-2.13.8-temurin%408%2Ftargets.tar
##### Begin Diagnostic HTTP information #####
Status Code: 400
Status Message: Bad Request
Header Information: {
  "cache-control": "no-store,no-cache",
  "pragma": "no-cache",
  "transfer-encoding": "chunked",
  "content-type": "application/json; charset=utf-8",
  "strict-transport-security": "max-age=2592000",
  "x-tfs-processid": "d1684538-5dcb-4a3f-8745-537477d6a514",
  "activityid": "451083d9-565b-4d05-bc87-ee9e822f2860",
  "x-tfs-session": "451083d9-565b-4d05-bc87-ee9e822f2860",
  "x-vss-e2eid": "451083d9-565b-4d05-bc87-ee9e822f2860",
  "x-vss-senderdeploymentid": "02120909-3c00-63c2-b451-f147b8aff5a4",
  "x-frame-options": "SAMEORIGIN",
  "x-cache": "CONFIG_NOCACHE",
  "x-msedge-ref": "Ref A: 4C7B648E7A42422797C334697F30AC46 Ref B: SN1EDGE1721 Ref C: 2022-01-18T20:58:59Z",
  "date": "Tue, 18 Jan 2022 20:58:58 GMT"
}
###### End Diagnostic HTTP information ######
Warning: Aborting upload for /home/runner/work/jawn/jawn/targets.tar due to failure
Error: aborting artifact upload

Continue offering non-CI/GHA versions of plugins

This one comes from @bpholt, to avoid issues with sbt-project-matrix which doesn't play nice with sbt-gh-actions. The current setup caters perfectly fine for this use-case (e.g., the separate sbt-typelevel-sonatype and sbt-typelevel-sonatype-ci-release plugins. It's a minor tax on this repo, but much more friendly to downstream.

Remove `sbt-dependency-graph`

That's more of a developer tool that should be installed by developers themselves if they find it useful. I wouldn't mind or mention anything if it wasn't for the fact that its presence in sbt-typelevel is interfering with my own (more recent) installation of the sbt-dependency-graph in my global sbt settings.

`prePR` command—or another solution to fatal-warnings-in-CI

Spinning out of #12 (comment).

The underlying problem is we often want fatal warnings in CI, but not locally since it makes development/experimentation annoying. But then, we end up fighting CI :)

One proposal is we add a prePR command that emulates a CI compile, by cleaning and enabling fatal warnings (if that is indeed how CI is configured).

Automatically collect all no-publish projects

Inspired by a comment in the http4s build:

// TODO would be nice if these could be introspected from noPublishSettings

The idea would be to have some collection (or event a rootNoPublish) that automatically aggregates all the projects that have had the NoPublishPlugin enabled.

Sort prereleases by number within them (e.g., M9 < M10)

Context: https://github.com/typelevel/sbt-typelevel/pull/12/files/ddf26e78666fdce3953581dd99e7a49ea79d4111#diff-f515c6fb650430625373f4dee21cd53c79e9464b0ab728b8fa02b25ee2dd6f47

Platform-cross-aware GHA steps

When you define an sbt step in sbt-gh-actions, it automatically prefixes the step with e.g. ++2.13.7 to set the Scala version as defined in the matrix.

When a matrix is split on platform (JVM/JS/Native), it would be helpful to have a step prefixed with e.g. project rootJVM or project rootJS with whatever is defined in the matrix.

I think this is possible, something like this: just as we have axes for OSes, JVMs, and Scala versions in the matrix, we need an axis of "aggregate projects". Each aggregate project would select a slice of sub-projects in the build (e.g., JVM ones or JS ones) and scope all the sbt steps in the workflow to that project, just like they are scoped to a particular Scala version.

I think this might also fix sbt-gh-actions' interop with sbt-project-matrix, which creates one sub-project per Scala version and thus wreaks havoc.

Linking to #18.

Add some tests, scripted and non-scripted

I think there are some good ones in sbt-spiewak we can adapt. Haven't checked the davenverse.

Steward PRing sbt-typelevel updates?

I've been watching doobie which is currently on sbt-typelevel v0.4.0-M3 hoping that it will get a Steward update to M4 which was released a couple days ago, but so far this hasn't happened.
https://github.com/tpolecat/doobie/blob/59bf85ab1a8482abd18ba9f026c43ee9d48e304b/project/plugins.sbt#L4

Now more projects are using sbt-typelevel, and I just cut an M5 with a bug fix, so I want to make sure updates are working.

@fthomas would you mind helping with this? Thank you :)

Current version should not be included in previous MiMa artifacts

Another one from typelevel/fs2-grpc#478.

I.e. if you are building a tag for x.y.z, x.y.z should not be in the previous artifacts to compare against.

"release" scripted test is broken with Java 8

I'm getting:

[info] [info] Compiling 1 Scala source to /private/var/folders/gp/x9y63xzj29j1c94wh2r26yxc0000gq/T/sbt_35f4eec7/release/target/scala-2.9.3/classes...
[info] [error] error while loading AnnotatedElement, class file '/Library/Java/JavaVirtualMachines/jdk1.8.0_20.jdk/Contents/Home/jre/lib/rt.jar(java/lang/reflect/AnnotatedElement.class)' is broken
[info] [error] (bad constant pool tag 18 at byte 76)
[info] [error] one error found
[info] [error] (compile:compile) Compilation failed
[info] [error] Total time: 2 s, completed 27-Nov-2014 23:09:52

	- name: Publish project
	run: sbt ++${{ matrix.scala }} +publish