sfdx force:source:push failing since the latest stable update 7.144.2 #1466
Comments
|
Thank you for filing this issue. We appreciate your feedback and will review the issue as soon as possible. Remember, however, that GitHub isn't a mechanism for receiving support under any agreement or SLA. If you require immediate assistance, contact Salesforce Customer Support. |
|
Hi @sesh-kebab 👋 thanks for reporting this. I just want to verify that you're setting |
|
Hi @WillieRuemmele , correct using it as described, by adding it to sfdx-project.json. |
|
ok, is this happening every time you've ran the |
|
Sure, i'll give that a try. But a couple of other data points if they might help:
|
|
Additional excerpts with sfdx force:source:push (SOAP)sfdx force:source:push (REST) |
|
I'm having a hard time reproducing this. I created exactly 7,411 ApexClasses in the first package, and 213 in the second to mimic the size of your deployment and both commands failed with the and I then reduced the ApexClasses by 2 (because there are 2 files for each) so that maybe the zip files would be similar to your size and |
shetzel
added
more information required
|
Our static resource folder is also around 45mb in size with 208 files. Not sure if the could also be a contributing factor? Thanks for suggesting the workaround of |
no-response
bot
removed
the
more information required
|
@sesh-kebab - can you please set the |
shetzel
added
the
more information required
|
I have similar issue but without too many files error message. Push with new CLI version is not working anymore while legacy push is working. I push all metadata in one push, 4700 components and size is around 40 mb but no big static resource folder in my case Lot's of errors related to missing fields and class error compilation. In deploy UI seems that the first error causing the others is this one I'll try the above procedure to try to give more info |
|
@WillieRuemmele I had a chance to try the sfdx force:source:deploy --tracksource (output obfuscated)Seems similar to what @LionelSchroder is seeing (although I'm not sure what deploy UI is?) @shetzel trying the legacy push and normal push with the temp dir overriden, I'm seeing the following
And when I drill into each of the respective metadata folders, I'm seeing Apart from the Checking the number of files however, I'm seeing 218 additional files when not using legacy I was examining what the additional files could have been when I noticed the To rule out any issue with multiple package directories, I used a different sfdx-project.json which only included a single package directory, so that the metadata temp folders would be almost identical in size and file count; that still resulted in "ERROR running force:source:push: INVALID_OPERATION: Too many files in zip" message. Does this help? |
|
First time I had the issue, as there is too much errors the output in my terminal was truncated. In UI the order of the errors is not the same as the one in the terminal. I was wondering if first error in UI could be at the origin of the others. That's what I was talking about : |
|
@shetzel I work with Seshi in the same project. I tried your suggestion by setting the SFDX_MDAPI_TEMP_DIR env var to some temp dir, then run push commands in two versions. I use old version V7.143.0 and new version V7.146.1 for comparison. |
|
@LionelSchroder @dyytina I'm picking up this investigation. I have a theory: can one of you share your you can also run the |
|
Here is the screenshot of .forceignore file |
|
Please let me know if you need more information on this ticket. Thank you! |
|
seems to be stuck with @mshanemc please let us know if you need anything more? the issues in the original description are still present as of 7.147.1 sfdx cli. |
|
My error is solved with 7.149.1 |
|
@LionelSchroder unfortunately I'm not having the same luck. Although the errors about size are no longer present with Not sure why the first two 'omDashboardLinkWorker' & 'omDiscreteModalHlp' could be throwing this error. But the second two are not duplicate LWCs but identically named components in different folders. That could be why but this wasn't causing an issue previously and can confirm using |
|
@sesh-kebab if you've got the same-named component in two different folders, You can modify your project.json to make regular [and then decide if you really mean to have identically named components because that's weird and likely to cause other problems with merging/tracking since the server doesn't know about your local folders] |
|
Thanks @mshanemc, all. I'll close this case as I'm no longer working on this and will leave it up to the other participants to create a new case and link back to this case if needed. |
Summary
Latest sfdx-cli, 7.144.2 has broken pushes for our codebase.
Steps To Reproduce:
Unable to provide a sample repository but when push was working it would push approximately 7,600 components (between two packages 7,400 and 200 in another) files along with a static resource directly that was greater than 50mb to give you an idea of approximate size that this issue is reproducible in.
Create a new scratch org and set as default scratch org.
pushPackageDirectoriesSequentiallyhas no effect). We have two packages in a single namespace so I would have expected this to make a difference if it works as intendedExpected result
Source for multiple packages should be pushed without using legacy.
Actual result
Failed with "Too many files in zip" error. Attempting to use workarounds of:
pushPackageDirectoriesSequentiallyattributeboth failed with different set of errors as described above.
System Information
The text was updated successfully, but these errors were encountered: