Skip to content
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

Closed
krzema12 opened this issue Feb 1, 2023 · 4 comments
Closed

Add action typing #1574

krzema12 opened this issue Feb 1, 2023 · 4 comments

Comments

@krzema12
Copy link

krzema12 commented Feb 1, 2023

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.

@peter-evans
Copy link
Owner

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.

@krzema12
Copy link
Author

krzema12 commented Feb 3, 2023

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.

@peter-evans
Copy link
Owner

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.

@krzema12
Copy link
Author

krzema12 commented Feb 3, 2023

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants