-
-
Notifications
You must be signed in to change notification settings - Fork 434
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add action typing #1574
Comments
Hi @krzema12 This is very interesting, but I'm not keen on having things committed to this repository to support it. Presumably, there will be some configuration on the library-side to support this action. If you let me know where it is then I would be happy to keep it up-to-date when there are changes to action inputs. |
Hi @peter-evans! I'm curious about the reason of your decision. Is it because you don't want to couple with a single library far away from your action? I like to think of github-actions-typing as of something language and library-agnostic, and also a way to formally document your action's API with regards to the types of accepted inputs and returned outputs. I'm encouraging you to reconsider given this point of view. In the meantime, we can try what you propose. The configs live here: https://github.com/krzema12/github-workflows-kt/tree/main/actions/peter-evans. Long-term I'm not planning to maintain these in the library, so I'm in the middle of an effort of asking action maintainers to take care of typing their own action(s) because that's the way to go when we talk about scalability. It's meant to fix what GitHub didn't introduce together with introducing Actions. |
Hi @krzema12 If I accept code/config into my repository it means I am now the maintainer of that code. So what you are really asking me to do is maintain code for your project. I've had requests to accept code for other projects in the past and always declined for this reason. I think it's a really cool idea, but I wonder if the approach needs to be different. I don't think it's reasonable to ask action maintainers for the entire eco-system to accept code/workflows. I don't know what a good solution would be, but one thing to consider is that a lot of popular actions are Typescript and already have types. If something like this ever became a standard that GitHub officially support, then of course I would reconsider. |
I guess it depends on the point of view - I perceive the types as in fact being a part of your project, expressed/surfaced/documented with help of my project 😉 The TypeScript typings are, well, tied to TypeScript. My solution uses widely spread and easy-to-parse YAML. I guess we could call it a personal preference. Of course I respect your decision here, while I'm happy when action owners are happy to introduce this kind of documentation. Thanks for the discussion! |
I'm looking to get your action first-class supported by https://github.com/krzema12/github-workflows-kt, a Kotlin DSL to write GitHub Action workflows.
They came up with a way to reduce operational load when keeping library's action wrappers in sync with actions' inputs and outputs. The solution includes onboarding https://github.com/krzema12/github-actions-typing. It's as easy as adding an extra YAML file to your repository root, and adding a simple GitHub workflow that validates this new file. Thanks to this, the code generator in the Kotlin DSL can fetch typing info provided by you instead of them, which has a number of benefits. It has no negative effects on current action consumers, they continue to use the action via regular GitHub API, as if the file wasn't there.
In this feature request, I would like to ask you if you're open to introducing such typings in your action. You wouldn't be first - there're already other actions using it, like e.g.: https://github.com/Vampire/setup-wsl or https://github.com/ReactiveCircus/android-emulator-runner (full list here).
If your answer is "yes", feel free to either add it yourself, or let me know - me or some of the library contributors would be happy to post a PR. They're also open to any kind of questions and feedback.
The text was updated successfully, but these errors were encountered: