Replies: 5 comments
-
This would be awesome, I was searching for this feature too. Its actually pretty common for version creation commands to have a "dry run" option where everything is checked but no version is created. |
Beta Was this translation helpful? Give feedback.
-
I can try to get the packaging team's eyes on this since it would have to come from them. You might try getting attention using https://ideas.salesforce.com as well. |
Beta Was this translation helpful? Give feedback.
-
Great suggestion. I would suggest the flag be |
Beta Was this translation helpful? Give feedback.
-
Yes, |
Beta Was this translation helpful? Give feedback.
-
Is your feature request related to a problem? Please describe.
I am frustrated by the complexity of CI pipeline with packages. It is very hard to implement and incomplete by nature. Yes it's possible to use SubscriberPackageVersion object to get the dependencies for an existing package version but what if you try to test the build of a not yet created version that needs new dependencies?
Here are the steps for CI with packages that I implemented:
And even with all these steps passing, I can still get errors when creating a package version -- because of a duplicate metadata in another dependency for example. Unfortunately there is no way for me to test the creation of a package.
What are you trying to do
I would to have a single command that does all of that without having this complex script for CI. I don't want package versions to be created at every commit on feature branches but I would like to know the state of the creation of the package at this point.
Describe the solution you'd like
All the steps I mentioned earlier are the one covered by the
--codecoverage
tag. I would love to have another tag--checkcreation
that do the same but actually don't create the package version. That would allow me to have a single line for my CI script:sfdx force:package:version:create -x -p xxxxxx --codecoverage --checkcreation
No need to create scratch org, no need to install dependencies, no need to deploy anything, no need for a test suite.
Describe alternatives you've considered
The only alternative I considered was to have a dedicated version number (major, minor and patch) to test the creation of the package from feature branches. Unfortunately as versions can't be deleted and I work with a very large team and more than 20 packages, we are already experiencing timeouts with
package:version:list
. So for now I don't have any other alternatives to create package versions on release branches and though taking the risk to face issues after merges.Beta Was this translation helpful? Give feedback.
All reactions