-
Notifications
You must be signed in to change notification settings - Fork 0
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
RFC: Switch to JS from Docker #1
base: master
Are you sure you want to change the base?
Conversation
I'd like this project to have access to the configured host language and tools so that I can call installed binaries that are unique to the previous steps context.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice. Until we have some iterations and success with these, we should expect to stumble a bit. I'm curious how these perform on secondary runs (does the GHA system produce a cached artifact, etc). Something to watch.
Another big thing I like here, is this COULD detect the tooling and know what to do. And further more it could take other actions on the docs.
Agreed, now that I'm running in the same scope, I could easily detect a Gemfile and call I'm also thinking about how we could get this all pushed up to S3, but then make a full site on netlify with security or something. 🤔 |
Last night I was struggling to get this Docker based action to work. In the end I occurred to me that there was no way the "Docker" container was going to have access to the "workers" installed tools. So in this case I was unable to call yard because it just didn't exist.
Based on my reading of the node based actions, plus looking at the language based actions (like the one that adds ruby) it looks like we need to use the node approach if we want this action to generate the docs.
If we just want this to publish the docs, then we can keep with the docker approach.