I don't understand this reasoning 🤷 https://github.com/microsoft/setup-msbuild/issues/109

But yeah, the reasoning makes no sense to me either, probably did not read the request properly or didn't understand

BTW, I sent like ~15 tickets to encourage onboarding github-actions-typing yesterday, and planning to send more (omitting just GitHub’s first-party actions for now). Tracking here: https://github.com/krzema12/github-workflows-kt/issues/567 if you (plural) would like to help me in this effort, feel free to write to any action owner and then paste a link to the ticket in the comment. It’s just a tedious copy-pasting job, no creative process for now 🙂

Although I'd say that politically Microsoft is unlikely to accept changes related to how github-actions operates

Thanks guys for your support here so far!

another interesting case: https://github.com/peter-evans/create-pull-request/issues/1574#issuecomment-1415032011 - the owner is kinda interested in maintaining the typings, but not in his repo(s)

another interesting case: https://github.com/peter-evans/create-pull-request/issues/1574#issuecomment-1415032011 - the owner is kinda interested in maintaining the typings, but not in his repo(s)

I think same problem as with the MS repo. The text is written wrongly. It focuses on getting the action supported in

github-workflows-kt

. This easily leads to "why should I do their work" thoughts (not with this guy obviously, but he still see the main benefit of the PR to support your lib). Instead you need to rephrase the text to focus on the benefit for the action you are creating the PR for. That it provides typings for the users and so on. And merely mention as side-effect that libs like yours can use it to generate classes properly. Basically similar to my first comment on the MS PR. The action author needs to mainly see a value for himself, his action, and his users, not for you, having less work to do.

Ah, I see you already did and released 👌

I’m hoping 🤞 to automate it further one day

It still needs to be released

@Vampire and others: I'm open to feedback on https://github.com/krzema12/github-actions-typing/wiki/Request

A popular argument against: adding a tool in the user space instead of first-party support: https://github.com/docker/build-push-action/issues/789#issuecomment-1416698087 (which would be ideal, but yeah - GitHub doesn't care as much as we wish)

@Vampire and others: I'm open to feedback on https://github.com/krzema12/github-actions-typing/wiki/Request

I think I would not completely leave out github-workflows-kt, but indeed mention that it then can use that file to generate classes to conveniently use the action in Kotlin DSL for creating GitHub workflow files. That also shows a nice use-case and might even bring some new users.

Marking the action: yeah, good idea, I thought about it as well. Tracking it in the issue I shared at the beginning is not ideal

Anyone has a few minutes for posting a PR? https://github.com/supercharge/mongodb-github-action/issues/44#issuecomment-1416777944 I'm on the go, will be able to create one tomorrow or next week

(turns out it's not impossible from a phone ;) )

🤷 https://github.com/actions/stale/pull/830#issuecomment-1429817482 like if my arguments about automation wasn’t really understood

🤷 https://github.com/repo-sync/pull-request/issues/131#issuecomment-1433283763 - wonderful idea, but...

It's really hard to talk to people somehow. I prefer chatbots, they are more logical

Or maybe you should get some other automation to use the type information, so that you can say this and that and that and that can then use your action conveniently. As long as it is just the one lib, it is actually just shifting maintenance burden from you to them, if they don't see the documentation value for people anyway that is.

Or maybe you can ask again after wider adoption in other actions.

Better have a look at my typing suggestion. :-D

It's not up to date with the latest changes of course, but it is some preliminary suggestion anyway, and needs you to add tests and maybe more places or whatever, like for hard-coded classes that are not generated maybe. I just played with the generation afair

If you never did it, it is quite a hurdle, but there are good guides and on the 2nd time it is trivial.

Maybe getting the singing working with generating a key and so on is actually the harder part if you never did something similar before.

Which is the reason many people use JCenter for publishing instead, or 🤮 JitPack for publishing 🤮

see several recent commits where I adjust to the new group ID

the secrets are in theory in place - in theory because I see they exist, but I don’t know what sits inside them. So far the values were correct, but I was moving the repo to the new organization, so maybe something broke…

You can ask for them " Let me publish under com.myname.*" or "Let me publish under com.myname.myapp" If you did the second, changing the group to "com.myname.myotherapp" will get you a failure

publishing {
   repositories {
      maven {
         val releasesRepoUrl = uri("<https://s01.oss.sonatype.org/service/local/staging/deploy/maven2/>")
         val snapshotsRepoUrl = uri("<https://s01.oss.sonatype.org/content/repositories/snapshots/>")
         name = "deploy"
         url = if (Ci.isRelease) releasesRepoUrl else snapshotsRepoUrl
         credentials {
            username = System.getenv("OSSRH_USERNAME") ?: ossrhUsername
            password = System.getenv("OSSRH_PASSWORD") ?: ossrhPassword
         }
      }
   }

In Kotest it's also with that path https://github.com/kotest/kotest/blob/70d21f85419fe238dd961e54eb41320ab0d40cc8/buildSrc/src/main/kotlin/kotest-publishing-conventions.gradle.kts#L45

Once again updated the

type-safe-inputs-and-outputs-wiring

branch to the latest

main

🙂