Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 06:43

    blast-hardcheese on master

    Altering pr-label cacher set -e Update sbt-scalafix to 0.9.33 and 1 more (compare)

  • 06:43
    blast-hardcheese closed #1326
  • Nov 28 23:21
    codecov[bot] commented #1326
  • Nov 28 23:21
    codecov[bot] commented #1326
  • Nov 28 23:21
    codecov[bot] commented #1326
  • Nov 28 23:21
    codecov[bot] commented #1326
  • Nov 28 23:20
    codecov[bot] commented #1326
  • Nov 28 06:09
    blast-hardcheese closed #1312
  • Nov 28 06:09
    blast-hardcheese commented #1312
  • Nov 28 06:09

    github-actions[bot] on cli-v0.67.1

    (compare)

  • Nov 26 18:32
    blast-hardcheese synchronize #1326
  • Nov 26 17:55
    github-actions[bot] labeled #1326
  • Nov 26 17:48
    scala-steward opened #1326
  • Nov 24 18:17
    blast-hardcheese labeled #1325
  • Nov 23 23:45

    github-actions[bot] on guardrail-v0.69.0

    (compare)

  • Nov 23 22:49

    github-actions[bot] on scala-http4s-v0.69.0

    (compare)

  • Nov 23 22:48
    blast-hardcheese labeled #1324
  • Nov 23 22:47
    blast-hardcheese labeled #1323
  • Nov 23 22:45

    blast-hardcheese on master

    Removing build.sbt from release… (compare)

  • Nov 23 22:20

    blast-hardcheese on master

    Fix regression tests filtering … Add http4s 0.23.6 support Some final observations around … and 1 more (compare)

kelnos
@kelnos:matrix.org
[m]
(or in the meantime the gradle plugin can just depend on the cli artifact)
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
yeah
I really like the fact that coursier is able to just dynamically link and emit a standalone CLI artifact, btw. No need to publish the assembly like I used to do
kelnos
@kelnos:matrix.org
[m]
yeah, that's really cool
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
OK, here's #2. I split out and cleaned up the backreferences between the CLI runners, so now extending CLICommon is much more clean. Previously it was a mess because parseArgs was incorrectly part of CoreTerms, so we had a circular reference thing that mucked everything up. guardrail-dev/guardrail#1213
Also waffling about whether to merge ProtocolGenerators into one big interface instead of this somewhat split out mess, especially since we have useful copy methods.
Probably do that in a later PR if that does happen.
kelnos
@kelnos:matrix.org
[m]
blast_hardcheese: gave it a quick skim, looks good
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
kelnos appreciated
Nick Hudkins
@nickhudkins
@blast_hardcheese:matrix.org you still at Twilio and if so are y'all still actively using guardrail?
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
@nickhudkins: I'm not at Twilio anymore, but yes, they're still actively using it. A number of others in this channel do work at Twilio, though
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
@sideeffffect 👋 Thanks for your work on this upgrade! Once this is in I'll cut a release with your change as well as the http4s body validation failure stuff, likely later today Pacific US time
Considering we're doing this change all inside guardrail, as well as with Ross Baker's response, I think it should be safe to close the http4s PR as well
Ondra Pelech
@sideeffffect
:thumbsup:
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
0.65.0 released, with the new modules! sbt-guardrail is published, I'll do guardrail-maven-plugin tomorrow
Need to upgrade the syntax on the http4s samples so that the new plugin version compiles with those 🤔
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
Gonna need to get one of these going as well. Plan is to have one release-drafter configuration per module, accumulating PRs that impact that module, and when that release is cut it'll just run the release for that one module. release-drafter/release-drafter#935
unsure what the deal is going to be with the old guardrail module though. I think that'll just end up getting rolled into core, with a provided-scope dependency on the different modules. That way the interfaces stay the same, but when they change in core that'll also trigger a republish of the main guardrail dep.
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
That was much more frustrating than it probably should have been, but I think this should work. guardrail-dev/guardrail#1230
kelnos
@kelnos:matrix.org
[m]
that looks... complicated
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
kelnos Each module tracks commits that roll up to it, based on a file prefix filter. If you finalize the draft release for scala-http4s, it'll just release that one module. The next time a depending module is released, it'll pick up the most recent version of that module from the git tags and use that published artifact
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
I think the thing that would knit everything together would be a github action that just goes "release everything", where it knows about the reverse dependencies of the modules and bubbles everything back up to the main guardrail release
but it was great to see this actually work. I have a test repo here: https://github.com/blast-hardcheese/multi-release-drafter-test/releases
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
(also, aggravatingly, github doesn't permit on: release triggers to be filtered in any way, so my initial assumption about that being clean are also invalid. Gonna have to refactor that to avoid spam in the Actions tab)
but other than that, it does seem to be working. Releasing core now.
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
do'h. Everything worked, except of course the dependsOn versions ended up pulling their git desc version numbers instead of real versions.
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
OK, that time it worked.
kelnos
@kelnos:matrix.org
[m]
nice!
kelnos
@kelnos:matrix.org
[m]
blast_hardcheese: sbt-version-policy? better than mima?
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
I believe mima is used under the hood
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
Yeah, it does kelnos
kelnos
@kelnos:matrix.org
[m]
ah, cool
Ondra Pelech
@sideeffffect

Hello, is guardrail supposed to support specifying multiple response types?
As in https://swagger.io/docs/specification/describing-responses/#media-types

          content:
            application/json:
              schema:
                $ref: '#/components/schemas/ArrayOfUsers'
            application/xml:
              schema:
                $ref: '#/components/schemas/ArrayOfUsers'

https://spec.openapis.org/oas/v3.1.0#parameterContent
When I did that with guardrail, the generated code contained only the last defined

kelnos
@kelnos:matrix.org
[m]
@sideeffffect: java or scala? which framework?
Ondra Pelech
@sideeffffect
Scala, http4s in particular
Ondra Pelech
@sideeffffect
To clarify my use-case -- I would need to have different schema based on the Accepted header, like
          content:
            application/json:
              schema:
                type: object
            application/x-protobuf:
              schema:
                type: string
                format: binary
                x-scala-type: fs2.Chunk[Byte]
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
@sideeffffect: We only generate handlers for content-types that are known by guardrail internals. Without any changes, you can combine manually handled routes with the guardrail generated ones, reusing any guardrail-generated support classes where applicable
blast_hardcheese
@blast_hardcheese:matrix.org
[m]

So an interesting side effect of the module system that I hadn't considered, when a release-drafter release is cut, the tag is minted immediately. This has the effect of all subsequent runs compiling against the ABI exposed by the compiled modules in the source trees, but publishing POMs that refer to the tagged module versions.

The implications of this are that so long as you click release on the various drafts in the reverse-depends order, you can just release everything at once, and as the modules trickle up to bintray, they'll all be pointing at the right versions of stuff

the downside is that this isn't obvious, so if core's ABI breaks but it isn't released, then something that depends on core is released, it will be compiled against the new ABI but depend on the previous ABI.
The upside is that this all still happens at compile-time, not at runtime, so any goofs here manifest as inconveniences for the users, not runtime incidents.
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
kelnos Holy moly. The classloader stuff was annoying to work around. Much more so than I anticipated due to the strictness of classloading block members. I needed an indirection class in order to get it to work at all, but what I ended up with ends up with all the core deps being included in sbt-guardrail and friends, but by default if you try to use anything, you end up getting
sbt:guardrail-sample-http4s> compile
Missing dependency: guardrail-scala-http4s
[error] (Compile / guardrail) dev.guardrail.sbt.CodegenFailedException
[error] Total time: 0 s, completed Oct 14, 2021 6:31:52 PM

If I then stick

libraryDependencies += "dev.guardrail" %% "guardrail-scala-http4s" % "0.65.3-8-ga447b33-SNAPSHOT"

into project/plugins.sbt, it runs and generates sources, compiling successfully

Can you think of anything at a high level that I'm blundering into here, or does this still make sense enough to you that I'm not going to just crash this whole thing into the ground?
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
I did some analysis to track how classes were split into the various modules, as well as repackaging, as well as inner classes being moved to new objects: https://gist.github.com/blast-hardcheese/1c4dcfe2151510dfc87ec8e384d87cd1
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
Snapshots of the above have been published, things look good so far.
// Stick this in your project/guardrail.sbt or project/plugins.sbt, wherever you currently have the guardrail addSbtPlugin
resolvers += "Sonatype OSS Snapshots" at "https://s01.oss.sonatype.org/content/repositories/snapshots"
addSbtPlugin("dev.guardrail" % "sbt-guardrail" % "0.65.4+4-8fd0a0c5+20211015-1748-SNAPSHOT")

// stick these alongside the addSbtPlugin in whatever file you ended up using above
libraryDependencies += "dev.guardrail" %% "guardrail" % "0.65.4-31-g5de1766-SNAPSHOT"
libraryDependencies += "dev.guardrail" %% "guardrail-cli" % "0.65.1-31-g5de1766-SNAPSHOT"
libraryDependencies += "dev.guardrail" %% "guardrail-core" % "0.65.3-31-g5de1766-SNAPSHOT"
libraryDependencies += "dev.guardrail" %% "guardrail-java-async-http" % "0.65.1-31-g5de1766-SNAPSHOT"
libraryDependencies += "dev.guardrail" %% "guardrail-java-dropwizard" % "0.65.1-31-g5de1766-SNAPSHOT"
libraryDependencies += "dev.guardrail" %% "guardrail-java-spring-mvc" % "0.65.1-31-g5de1766-SNAPSHOT"
libraryDependencies += "dev.guardrail" %% "guardrail-java-support" % "0.65.1-31-g5de1766-SNAPSHOT"
libraryDependencies += "dev.guardrail" %% "guardrail-scala-akka-http" % "0.65.1-31-g5de1766-SNAPSHOT"
libraryDependencies += "dev.guardrail" %% "guardrail-scala-dropwizard" % "0.65.1-31-g5de1766-SNAPSHOT"
libraryDependencies += "dev.guardrail" %% "guardrail-scala-endpoints" % "0.65.1-31-g5de1766-SNAPSHOT"
libraryDependencies += "dev.guardrail" %% "guardrail-scala-http4s" % "0.65.3-31-g5de1766-SNAPSHOT"
libraryDependencies += "dev.guardrail" %% "guardrail-scala-support" % "0.65.1-31-g5de1766-SNAPSHOT"
Start with just the plugin, then add whichever the plugin tells you that you need
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
guardrail-dev/guardrail#1300 starting to make it easier for iterating on a single module. Might be useful to .aggregate(dependents % "test") when working on a module to ensure related modules' tests also get run