[Blocked] Warnings about unexpected inputs
dgholz opened this issue · 26 comments
Hello, I have a step in my workflow like:
- name: Get count of commits ahead of merge base
id: github_compare
uses: octokit/request-action@v2.x
with:
route: GET /repos/:repository/compare/:base...:head
repository: ${{ github.repository }}
base: ${{ github.base_ref }}
head: ${{ github.ref }}
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
When the workflow runs, I see Annotations about unexpected inputs, and in the workflow output, I see:
##[warning]Unexpected input 'repository', valid inputs are ['route', 'mediaType']
##[warning]Unexpected input 'base', valid inputs are ['route', 'mediaType']
##[warning]Unexpected input 'head', valid inputs are ['route', 'mediaType']
Run octokit/request-action@v2.x
with:
route: GET /repos/:repository/compare/:base...:head
repository: dgholz/my_repo
base: master
head: refs/pull/1/merge
mediaType: {}
env:
GITHUB_TOKEN: ***
GET /repos/:repository/compare/:base...:head
> repository: dgholz/my_repo
> base: master
> head: refs/pull/1/merge
> mediaType: [object Object]
< 200 451ms
How do I prevent these warnings from appearing?
Unfortunately there is no way to prevent these warnings, it looks like they are a recent change in the GitHub Actions runner. All inputs that are not defined in the action.yml file now trigger this warning, and there is no flag to suppress them at this point 😭
I'll reach out to support and ask about it, we can leave the issue open for the time being
👋 I've received a report from users of an action I maintain with similar warnings.
In my case I define an input as a pattern rather than a static name to support user defined named sets of files included in a diff . The current action.yml file descriptor lacks an ability to express input names as patterns. Since inputs are just a conventionally named env variable in thier implementation I can have users just declare INPUT_ env names instead. That feels less than ideal for an interface.
Is there any other way to suppress these on an per-action level? I understand why GitHub might have added these warnings. In my case, it makes a working action look broken.
make sure to contact support at support.github.com/contact to let them know about your use case. It will bump the priority. And the more use cases there are, the better. I have hope that a setting to suppress these warnings will be added, the sooner the better :)
Nothing that I heard. Did you check in with support? I think they are aware of the problem, but I'm not sure what the current state is, i have no insights myself.
One issue is that the README in this repository suggests using the repository key, which raises this warning. Perhaps as an interim solution the README can be updated to note that this warning will be present but everything works as expected?
Very good idea! Would you like to send a PR?
@gr2m: Where is the actions.yml? Is it part of this repo, or the one that uses octokit/request-action?
The one in this repository: https://github.com/octokit/request-action/blob/master/action.yml
@gr2m: Can I open a PR with two dozen common input names to avoid the most frequent warnings?
sure, thank you!
I was expecting GitHub to fix that swiftly but looks like it got lost in the backlog.
also if you could reach out to https://support.github.com/contact as well that'd be helpful, it will prioritize the request to add some kind of flag to suppress warnings for undefined parameters
There is an open issue on the actions runner repository to address this problem:
actions/runner#514
The runner is open source and written in C#, I'm sure they'd accept a good PR. It's not something the actions team has currently on their roadmap.
Any traction on above Warnings issue?
I had a jackpot moment when I came across this action as it would save me on wrapping octokit steps in JavaScript (@actions/github-script), however those pesky warning Annotations are unpresentable to developers/business in a professional setting making every workflow look broken :-/
Can you reach out to support to bump the priority for getting this fixed? It’s been so long since there has been any movement in this :(
+1
+1
As a workaround you can pass inputs as env variables as follows:
- name: Get count of commits ahead of merge base
id: github_compare
uses: octokit/request-action@v2.x
with:
route: GET /repos/:repository/compare/:base...:head
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
INPUT_REPOSITORY: ${{ github.repository }}
INPUT_BASE: ${{ github.base_ref }}
INPUT_HEAD: ${{ github.ref }}@cardinalby thank you. Can you say me what is the solution for issues?
I use this:
- name: Issues
uses: octokit/request-action@v2.x
id: myissues
with:
route: GET /search/issues
q: 'repo:${{ env.myrepo }} milestone:"${{ env.mymilestone }}" label:"Bugfix","Label 1",Label 2"'
per_page: 100
env:
GITHUB_TOKEN: ${{ .... }}
If I do the same first without env variabeln I get no more results
- name: Issues
uses: octokit/request-action@v2.x
id: myissues
with:
route: GET /search/issues?q=repo:MYREPO
env:
GITHUB_TOKEN: ${{ .... }}
@KodaCHC It seems to be unrelated to this issue. The library may not allow query parameters in a route (but expects them in as separate params, as you showed in the first example). Back to the issue, try passing them as INPUT_Q and INPUT_PER_PAGE env variables if you want to avoid warnings.
Danke Thanks for the answer. How do I specify q without listing it under with?
See my initial answer, you can pass INPUT_Q env variable in env: section. It will work as if you set q input
Thank you. I misunderstood that. This works really well.
Lint code base
Unexpected input(s) 'auto_fix', valid inputs are ['entryPoint', 'args']
How can I Correct this and run the auto fix in the linter.
Shouldn't it be possible to have only a single variables input, that accepts an object with the custom keys? That one inut can be defined and wouldn't throw the warning.
Only issue is, that GitHub doesn't seem to support maps as input values directly, so the action would need to parse them, and in the config we would need to JSON stringify the object before passing it to the action.
I'm not sure if we implemented it for the action, but the underlying Octokit supports data for that, so you might be able to use it, just make sure you pass it as string
data: |
owner: ...
repo: ...
# etc I think it's less elegant though