Skip to content
This repository has been archived by the owner on Oct 17, 2021. It is now read-only.

Multiple inputs #1

Closed
fortmarek opened this issue Feb 17, 2020 · 10 comments
Closed

Multiple inputs #1

fortmarek opened this issue Feb 17, 2020 · 10 comments

Comments

@fortmarek
Copy link

Hi!

I was wondering if there is a way to define multiple directories as inputs parameter; unfortunately, it seems like Github actions do not support arrays, I have tried this approach, but for obvious reasons that did not work either.

One workaround (as mentioned here) would be to parse inputs with space as a delimiter. If that seems like worth the effort, I can try to have a look.

@mattt
Copy link
Contributor

mattt commented Feb 17, 2020

Hi @fortmarek. Could you achieve the same effect by running the action twice with two different inputs? As far as I can tell, the work done here should keep intact existing files that aren't overwritten:

debug "Enumerating contents of $1"
for file in $(find $1 -maxdepth 1 -type f -name '*.md' -execdir basename '{}' ';'); do
debug "Copying $file"
cp "$1/$file" "$tmp_dir"
done

@fortmarek
Copy link
Author

That, indeed, works, unfortunately, it is not a 100 % working solution since it overwrites _Sidebar.md (with list of types, etc.)

@mattt
Copy link
Contributor

mattt commented Feb 18, 2020

Wouldn't you have the same problem if it were possible to specify multiple inputs, though?

@fortmarek
Copy link
Author

Running swift-doc ACKategoriesCore ACKategories-iOS works just fine, so I reckon if the action was rewritten to something like this:

runs:
  using: "docker"
  image: "Dockerfile"
  # parsed inputs
  args: ["${{ inputs.path.first }}", "${{ inputs.path.second }}"]

it'd work just fine - as opposed to running what now boils down to swift-doc ACKategoriesCore && swift-doc ACKategories-iOS; or am I missing something?

Of course there is a question if you want to introduce such a workaround, but as a lot of Swift libraries do have multiple components, it might make sense to do so.

@mattt
Copy link
Contributor

mattt commented Feb 18, 2020

@fortmarek To clarify, this GitHub action only uploads contents to a project's GitHub wiki repository. Although swift-doc is the motivating use case, it can be used for any content.

@fortmarek
Copy link
Author

Right, sorry, I got sidetracked a little bit, this is really more about swift-doc itself.
The solution would have to be a little different - taking inspiration from here

There would have to be an intermediate script that would be triggered from action.yml and in that script you'd have to parse the multi-line string and only then run docker.

Which is a little bit complicated, unfortunately.

@mattt
Copy link
Contributor

mattt commented Feb 19, 2020

@fortmarek Sorry, but I'm still not 100% clear about what problem you're facing. Would you mind taking a step back to explain what you're trying to accomplish?

@fortmarek
Copy link
Author

Sure, sorry for making not myself clear. We have a library called ACKategories and for it we have two modules - ACKategories-iOS and ACKategoriesCore. Those translate to two directories.
Thus our project structure looks something like this:

-ACKategories
       -ACKategories-iOS
       -ACKategoriesCore

Locally, I can run swiftdoc ACKategories-iOS ACKategoriesCore --output Documentation to generate the valid documentation. That, unfortunately, does not seem to be possible using swiftdoc's github action.

@mattt
Copy link
Contributor

mattt commented Feb 20, 2020

@fortmarek Thanks for clarifying. I just filed SwiftDocOrg/swift-doc#19 to track the issue about array arguments.

Projects with multiple modules is absolutely something we want to support, but it may take some time to implement. In the meantime, though, you should be able to achieve what you're describing by running the swift-doc GitHub action twice with different input arguments?

@fortmarek
Copy link
Author

Yes, we recognize it as a known limitation and went with the solution you suggested and it works fine for now 🙂 thanks for the help (and the patience 😄 ).

Closing as the new issue is a more appropriate place.

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

No branches or pull requests

2 participants