https://kotlinlang.org
Join Slack
<github-actions-typing> got their first stable <v1.0.0 release>! Please remember about it when cont...
# github-workflows-kt
p
github-actions-typing got their first stable v1.0.0 release! Please remember about it when contributing typings to various actions, I've also updated the usage guide to point to v1
🎉 1
K 1
I don't understand this reasoning đŸ€· https://github.com/microsoft/setup-msbuild/issues/109
v
"They came up with a way", tztztz, as if it weren't you 😄
But yeah, the reasoning makes no sense to me either, probably did not read the request properly or didn't understand
p
poor copy-paste of your request from several days ago 😅 I’ll do better next time
v
Yep, I remember writing that 😄
p
thanks for your support! too bad we cannot reopen the ticket
l
I also pinged in that MS ticket
Although I'd say that politically Microsoft is unlikely to accept changes related to how github-actions operates
v
Well, it does not really change how it operates I'd say. And one of the 
actions/
projects is hopefully close to accept the PR, at least it has several positive reviews. And those are also Microsoft, just another team. 🙂
p
Wow, there's some progress in the MS's action, they're asking for a PR! The typings are here (to be double-checked): https://github.com/krzema12/github-workflows-kt/blob/main/actions/microsoft/setup-msbuild/v1/action-types.yml - anyone has a moment to prepare the PR while we have the guy on the line? I'll have a first chance to do so tomorrow
Thanks guys for your support here so far!
v
p
Thx @Vampire! 🙇
v
I also hope we can get https://github.com/burrunan/gradle-cache-action/pull/61 in before the release today
p
If it's not merged and released today, I can publish a patch release in a few days if you really need it fast
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)
v
If it's not merged and released today, I can publish a patch release in a few days if you really need it fast
Wouldn't have been necessary. But anyway, it was merged and released already. :-)
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.
p
great feedback, thanks! that’s basically the approach I used when writing the README in https://github.com/krzema12/github-actions-typing, not sure why I didn’t follow it when I sent these new tickets. I’ll write something better and share it with you for review
v
Do you do wrapper update during release process anyway, or do you need a PR for it?
Ah, I see you already did and released 👌
p
v
Does that also find new versions, so would you have needed the separate PR for v2 of my action or not?
p
there’s a separate semi-automated process for it, I get autocuts for these and then have to make the change manually
I’m hoping đŸ€ž to automate it further one day
v
setup-msbuild PR is merged
p
Hooray! 🎉
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)
v
Yeah, sad but understandable. Maybe somehow mark the action in 
actions/
as unwilling, so that not someone else gets the idea to ask again. :-D
@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.
p
☝ It's mentioned in the typing action's README
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
v
The readme might be too late. I doubt that person opened it. You have to have at least a basic interest to continue to the readme.
p
Ok, makes sense - added
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
It's really hard to talk to people somehow. I prefer chatbots, they are more logical
v
Well, that argument is perfectly valid and it was expectable that some will bring it.
p
if the idea is wonderful, why not support it and give the library a shot? maybe it’s me and my early-adopter nature
v
That, and that it is your idea, so you of course deem it wonderful, others might not. :-D Maybe for those people you have to try to emphasize instead again on this lib support. Maybe they would be more open to add it to be nicely supported here. đŸ€·
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.
p
thanks for the ideas, I feel I need some backoff time from this encouraging people thing, I’m feeling the burnout is close 😅 maybe after the pause, some new ideas come as well
v
Yeah, evangelizing is a hard task. :-)
Better have a look at my typing suggestion. :-D
p
can’t, I have to go back to work now 😅
v
Too bad. :-D
p
FTR, let me know what exactly you mean - was it about accepting expressions as action inputs?
v
Typed outputs and also accepting expressions as inputs, yeah
p
cool, I have it on my (priority) queue
v
I gave you a link to a branch with preliminary work for it
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
p
I hardly find time to perform basic maintenance and PR review these days, but yeah, I want to look at it eventually
v
I updated the 
type-safe-inputs-and-outputs-wiring
branch to the latest 
main
p
thanks, I’m tentatively planning to get back to it once moving to the new domain/Maven coords is done
v
The hardest part of that probably is getting the access from Sonatype 😄
p
already done
l
The hardest part of that probably is getting the access from Sonatype 😄
Really? I did that so many times I almost know it by heart. Do you think it's a big pain point? I never wrote a guide for it as I assumed people wouldn't need it.
v
Nah, not really, mainly joking 😄
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 đŸ€ź
p
I was so happy it was going smoothly, and then: https://kotlinlang.slack.com/archives/C19FD9681/p1680632933481859 😄 anyone has an idea?
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

l
You changed the group id? Need a new request to maven central
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
v
It's a completely different group and didn't we just talk about that he already did it? 😄 That step was what I referred to. You probably got me wrong. 😄
l
I'm confused
p
l
Copy code
publishing {
  repositories {

    maven("<https://oss.sonatype.org/service/local/staging/deploy/maven2>") {
      credentials {
        username = getenv("OSSRH_USERNAME")
        password = getenv("OSSRH_PASSWORD")
      }
    }
  }
Did you try with that /staging/deploy/maven2 part? I never used nexus publishing, always maven publish. Damn, that's a situation. I'm no longer confused
Copy code
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
v
The nexus publishing plugin is just a wrapper over the maven publishing plugin, that provides some convenience and mitigates some problems when publishing to a Nexus instance, especially Maven Central. (And provides tasks for closing and releasing the uploaded repository)
p
l
the env vars should be pascalCase
No fucking way 😂
v
If you don't like that, you can use system properties instead, for example using an environment variable. 😄
Copy code
JAVA_TOOL_OPTIONS="-Dorg.gradle.project.sonatypePassword=s3cr3t"
🙂
Once again updated the 
type-safe-inputs-and-outputs-wiring
branch to the latest 
main
🙂
p
☝ is it ready to create a PR with it?
v
Definitely not, or I would have. :-D It is just a quick PoC of my idea in https://kotlinlang.slack.com/archives/C02UUATR7RC/p1674635641684849?thread_ts=1674580678.412759&amp;cid=C02UUATR7RC that needs proper thought, tests, thinking about whether `List`s are handled the right way, ... It was just a quick throw-together of that idea and then generation adapted to it to make it compile again and tests green, to give you something more substantial to evaluate my idea.
p
This day will come!
5 Views
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by