-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
Release 6.13.5 #666
Release 6.13.5 #666
Conversation
PR-URL: #627 Credit: @felixonmars Close: #627 Reviewed-by: @ruyadorno
PR-URL: #569 Credit: @claudiahdz Close: #569 Reviewed-by: @ruyadorno
When you set `<cache>` directory in npm config, `npm ci` has been using `<cache>` for storing the cache instead of `<cache>/_cacache` PR-URL: #550 Credit: @zhenyavinogradov Close: #550 Reviewed-by: @ruyadorno
This will allow all builds to run even if one fails PR-URL: #601 Credit: @XhmikosR Close: #601 Reviewed-by: @ruyadorno
PR-URL: #603 Credit: @XhmikosR Close: #603 Reviewed-by: @ruyadorno
PR-URL: #600 Credit: @XhmikosR Close: #600 Reviewed-by: @ruyadorno
Paired with @ruyadorno PR-URL: #659 Credit: @isaacs Close: #659 Reviewed-by: @ruyadorno
2fe00b9
to
a5496c0
Compare
|
- Moved windows builds to travis-only since they're currently failing on GHA and it's not code-related - Added setup on GHA config to only run coverage once in ubuntu target
…nd git tag -f PR-URL: #648 Credit: @rhengles Close: #648 Reviewed-by: @ruyadorno
In wondered why npm link doesn't "install to" `npm prefix`. I looked up the documentation for `npm prefix` and found the important distinction between the local prefix, and the global prefix. This attempts to clarity that `npm link` always uses specifically the global prefix. PR-URL: #532 Credit: @jgehrcke Close: #532 Reviewed-by: @ruyadorno
c4e464e
to
6fb5dbb
Compare
@ruyadorno I'm mostly on Windows, so I might be able to pinpoint the Windows failures. I'll experiment on my fork, because ideally everything should be tested in one place. |
@XhmikosR thanks! that's really appreciated 😊 (I assume you're talking about e0a7a2f) It was not that big of a problem for this release since we still had the travis build around anyways but it would be definitely nice to track down what is happening and fix it. I can share some of the findings from our team so that you can get a head start, for now the problems only occur in the GitHub actions environment (we couldn't reproduce it on our local windows environments) and are related to |
@ruyadorno : thanks for the info :) That being said it seems CI is passing fine on my fork on Windows https://github.com/XhmikosR/cli-1/runs/383031136 Maybe you should try re-enabling it? BTW you can force the shell to be something other than the default which is powershell. https://help.github.com/en/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#using-a-specific-shell |
6.13.5 (2020-01-09)
BUG FIXES
fd0a802ec
#550 Fix cache location fornpm ci
(@zhenyavinogradov)4b30f3cca
#648 fix(version): using 'allow-same-version', git commit --allow-empty and git tag -f (@rhengles)TESTING
e16f68d30
test(ci): add failing cache config test (@ruyadorno)3f009fbf2
#659 test: fix bin-overwriting test on Windows (@isaacs)43ae0791f
#601 ci: Allow builds to run even if one fails (@XhmikosR)4a669bee4
#603 Remove the unused appveyor.yml (@XhmikosR)9295046ac
#600 ci: switch toactions/checkout@v2
(@XhmikosR)DOCUMENTATION
f2d770ac7
#569 fix netlify publish path config (@claudiahdz)462cf0983
#627 update gatsby dependencies (@felixonmars)6fb5dbb72
#532 docs: clarify usage of global prefix (@jgehrcke)