Replies: 4 comments 1 reply
-
Also, it appears that These can be found at:
docker-manifest-action/README.md Line 25 in acf2524 docker-manifest-action/README.md Line 52 in acf2524 I'm not sure, I haven't read the code, just the documentation, but aren't Sorry if some parts are difficult to understand due to the use of translation tools. |
Beta Was this translation helpful? Give feedback.
-
The behaviour is not expected. I'll create a new release making it not required.
This is also a mistake, I'll be fixing that also. :3
inputs is the same premise as base-image, where it is the inputs for the merged manifests to be created and images (
namespace/image:latest-amd64 and namespace/image:latest-arm64 will be merged into namespace/image:latest. Sorry for any misunderstanding with the documentation on translation tools as they are not accurately the best and I am also not good at speaking English even though it is my native language. I'll be updating the documentation to make it more understandable and have it peer-edited with the rest of the Noelware team. Thanks again for using this action~! 🐻❄️ |
Beta Was this translation helpful? Give feedback.
-
Thank you for your reply. Regarding
It is plausible that the decision should be based on the documentation, but we feel that it would be better if it could be uniquely determined by the key name if possible. |
Beta Was this translation helpful? Give feedback.
-
I would like that also, so I'll make this as a discussion rather than a issue (so that other people viewing/using this action can comment on it also!) |
Beta Was this translation helpful? Give feedback.
-
From the user-side, we feel that the current names and behaviour of
inputs
andimages
are confusing.Regarding
inputs
andimages
, the users of this action think that "passing multiple images to docker-manifest-action as input" will result in "one combined manifest image output".Therefore, each with-keys was considered as follows:
inputs
= "images to be merged as input"images
= "merged manifest image(s) to be created as output"This idea seems to differ from current implementations. It is plausible to judge by the documentation, but we believe that it is better to be able to uniquely judge by the key name if possible.
What is your opinion?
Discussion Comments before moving on (issue#134)
Hello, thank you for developing this great action.
v0.3.0 has been released, but applying this release without updating with will result in an error.
The job log where this is occurring is following: https://github.com/tomacheese/my-pixiv/actions/runs/4021878692/jobs/6911501009
Deprecations rather than Removed, so I assumed these would work with the update applied without any changes.
Is this behavior expected?
P.S. I have read the action.yml and I don't know why this error occurs even though
required: false
is specified.Well, I am concerned that
required: true
is specified in src/input.ts.Also, if possible, when configured deprecated inputs, please mention this in the
deprecationMessage
, so that appropriate warnings are displayed and easily noticed.https://docs.github.com/en/actions/creating-actions/metadata-syntax-for-github-actions#inputsinput_iddeprecationmessage
I look forward to your reply.
Beta Was this translation helpful? Give feedback.
All reactions