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

Allow simpler configuration for reusing actions and workflows #579

Closed
nickmccurdy opened this issue Sep 24, 2022 · 3 comments
Closed

Allow simpler configuration for reusing actions and workflows #579

nickmccurdy opened this issue Sep 24, 2022 · 3 comments
Assignees
Labels
feature request New feature or request to improve the current logic

Comments

@nickmccurdy
Copy link

nickmccurdy commented Sep 24, 2022

Description:
Ideally, I'd like the default configuration of this action to "just work" regardless of the package manager, lockfile, and other decisions made by a repository, so I can reuse it in composed actions and workflows. Currently, there isn't a straightforward way to enable caching without hard coding a specific package manager, and using pnpm requires adding different steps before this action, making its usage inconsistent with npm and yarn users.

I am aware of these related issues, but I wanted to make an issue dedicated to discussing how to achieve this goal at a higher level:

Justification:
As a real world example, I have a GitHub template repository that sets up some Node.js tools with a package.json file. To keep it beginner friendly and flexible, I'm intentionally not including lockfiles for any specific package manager. I considered setting up GitHub Actions so generated repositories would have a good CI setup, however there's not a single configuration I could enable for this action that would work with npm, yarn, and pnpm users.

Other CI services solve this problem by following convention over configuration. For example, Travis CI runs yarn instead of npm install when there is a yarn.lock.

Are you willing to submit a PR?

So far, I'd suggest that we depend on preferred-pm for more implicit package manager selection logic and use it to install yarn or pnpm dynamically (optionally with corepack). If there's consensus on this or another solution, I may try to submit a PR, though it may depend on PRs for the related issues.

@nickmccurdy nickmccurdy added feature request New feature or request to improve the current logic needs triage labels Sep 24, 2022
@dmitry-shibanov
Copy link
Contributor

Hello @nickmccurdy. Thank you for your report. We'll investigate the feature request.

@dsame
Copy link
Contributor

dsame commented Oct 6, 2022

Hello @nickmccurdy can you please clarify how this issue differ from this one #306 ? Namely what does the term "simpler configuration" includes? Or, in other words, what inputs besides cache: 'auto' you would like to inherit from the environment?

@dsame dsame self-assigned this Oct 7, 2022
@dsame
Copy link
Contributor

dsame commented Dec 13, 2022

@nickmccurdy i am closing the issue due to inactivity for a long time, but please feel free to reopen it or create another one if the problem still exists

@dsame dsame closed this as completed Dec 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request New feature or request to improve the current logic
Projects
None yet
Development

No branches or pull requests

3 participants