Guidelines for recipes

[allisonletts]

@MelanieTolomeo asked about whether there were any rules about what could be included in our recipes. I'd like us to expand on this section of the readme

My initial feelings:

• Packages must be SFDO or Open Source Commons so that we can reliably spin up scratch orgs with the right packages
• No other custom fields
• Clearly list any needed packages within the recipe
• Assume no automation beyond the package

[acrosman]

We have talked in past about being open to recipes for harder to test packages like Admissions Connect, Subledger, and Student Success Hub (all of which require additional licenses for full functionality). Scratch orgs are actually remarkably capably of getting those settings in place if we set them up right. So I think I'd rather suggest we stay open to those, but we may mark some things as having extra barriers to testing and therefore not getting the same level of review. They are still helpful to the community.

That said I think SIs and ISVs who have packages should maintain their own collections for their packages. They are of course welcome to join the recipe maker's chat in Slack for support but their recipes, like their packages, should be theirs to maintain.

[allisonletts]

Yes. Any SFDO package, free or paid, plus any OSC work should be able to live in here. For maximum usefulness to the community, I think we should limit the use of fields from other sources, including managed packages not from SFDO and one-off custom fields. For example, I don't think storing FinancialForce snowfakery templates in this repo is going to make a lot of sense. But also, I don't want to need to create a custom Nickname__c field every time I want to run a new recipe without it erroring out.

[acrosman]

The other fields to be careful of are things that appear in developer orgs but not all production orgs. We ran into this with some early recipes that tried to set values in all fields. We realized that recipes created against scratch orgs couldn't run against common sandboxes because there were differing features. This one gets exciting cause it's not always obvious which are which. But eventually defining which is the assumed edition of Salesforce for the recipe would be helpful.

[allisonletts]

Shouldn't that happen in our scratch org definitions and the flows we use? Since we're largely working on orgs that start with P10, could we use Enterprise as the default? Is there a standard org shape? @jesslopez-sf do you have any guidance here for how you set up scratch orgs that make sense?

[acrosman]

When it came up it the scratch orgs in use had no additional licenses enabled. They just had more features enabled by default than expected. I think having the standard for recipes encourage minimal field use, or only relevant field use, would probably get us there. It was when people attempted to set all fields that we got into trouble.

[jesslopez-sf]

@allisonletts and @acrosman - I agree with everything in this conversation. I think 9.999 times out of 10, I've used a developer edition (dev) with either the dev_org flow to get unmanaged code or the install_prod flow to get the managed package. I think I've only ever used snowfakery to populate scratch orgs in my day-to-day and very very rarely, a persistent org when scratch orgs didn't have enough storage to test with the volume of data I needed. I can definitely see how dev org-only remnants might cause issues in an enterprise sandbox, but I think we can catch those types of things during code review now.

[allisonletts]

Another element: schema checking requires .recipe.yml file extensions. That should be a rule. This line should be the first of every file:

# yaml-language-server: $schema=https://raw.githubusercontent.com/SFDO-Tooling/Snowfakery/main/schema/snowfakery_recipe.jsonschema.json