https://kotlinlang.org logo
Join Slack
Powered by
There is currently no way to get custom outputs fr...
# github-workflows-kt
v
There is currently no way to get custom outputs from an action that does not have outputs at all, for example because it was modelled wrongly or because the outputs were just added by the action developer. If I were to create a PR to fix that, how would you prefer it? I see three options: • Make any action have custom outputs available • Make 
ExternalActionStep
have a function 
withCustomOutputs()
• Make 
ExternalActionStep
have a property 
withCustomOutputs
p
I'd try merging the concepts of action and action with outputs (since given what you wrote, any action can have outputs), so the first option seems to be the most compelling one
I have no way to play with the code now, so let's experiment
BTW, is it a real-life case or a hypothetical one? Could you show which action has this issue?
When browsing actions, I see various kinds of weirdness, like not using inputs and all and using env vars instead (I don't want to support this case in the lib)
v
Not sure how the last comment is related to my question. But yeah, it is actually a theoretical problem right now. When playing with how to set the 
environment
in the other thread I had to search for an action that has outputs, and thought that all should potentially have outputs to keep the flexibility the lib has in most other places.
But yeah, it is actually a theoretical problem right now.
Does that mean you don't want that change until someone hits the problem and needed it or you would want it anyway if someone does the change? 😄
p
Let me put it like this: I'd like to track it as an issue in GH and focus on real problems/missing features first :)
Of course, if you prepare a PR, I'll appreciate it, but bear in mind that it will consume some of my resources to review and discuss, and maybe you'd prefer me to help with or implement another feature
v
Yeah, it's a dance on the volcano 😄
But no risk no fun 🙂
I gave it a shot and it was not that much changes, when ignoring the generated classes and test fixtures. 🙂
And it has the additional advantage that all output classes now share a common base class
p
Cool, thanks! Before I review, could you resolve the conflicts?
v
Ouch, that package refactoring is pure poison for that one. 😄
Sure, I'll rebase it of course
Done
p
@Vampire thank you, it's not only a feature but also simplification of internals ❤️
v
Yep, with no distinction necessary it simplifies things of course :-)
p
can I also ask you to update the docs? unfortunately we don't yet have kotlinx-knit (or equivalent) that would have catch it in the original PR
@Vampire ping - I’m planning to release tomorrow, let me know if you’re able to fix it or I should do it
v
p
CI now fails, I also see some other minor issues I’d like to discuss - are you fine with just fixing the docs for tomorrow’s release, and making this refactoring as a separate PR without rush?
v
Oh no. 🙈 Sure, no problem.
change incorporated and CI for the other PR should also be green now
p
awesome, thanks! will take care of them today evening
v
rebased 🙂
p
great job, danke 🙇
v
Immer gerne :-)
4 Views
Open in Slack
PreviousNext
Powered by