Merge branch 'main' into feature/deep-references-docs-and-stess-test-…

…case

.adr-dir

@@ -0,0 +1 @@
+docs/adrs

.coveragerc

@@ -8,3 +8,8 @@ exclude_lines =
     pragma: no cover
     @abstract
     raise NotImplementedError
+    raise AssertionError
+    def __repr__
+    def __str__
+    if T.TYPE_CHECKING
+    if TYPE_CHECKING

.github/workflows/ci.yml

@@ -10,7 +10,7 @@ env:
 jobs:
   test:
     name: "Python ${{ matrix.python-version }}"
-    runs-on: ubuntu-latest
+    runs-on: sfdc-ubuntu-latest
     strategy:
       matrix:
         python-version: ["3.8", "3.9", "3.10"]
@@ -36,13 +36,17 @@ jobs:
         run: |
           python setup.py install
           snowbench snowfakery/tools/benchmark_1.yml --num-records 10_000  --num-records-tablename Account --number-of-processes 4
-          snowbench
+          snowbench | tee bench.txt
+          tail -n 7 bench.txt >> $GITHUB_STEP_SUMMARY
 
   with_cci:
     name: With CumulusCI
-    runs-on: ubuntu-latest
+    runs-on: sfdc-ubuntu-latest
     steps:
       - uses: "actions/checkout@v2"
+      - run: |
+          git fetch --no-tags origin main:_remote_main_
+
       - uses: "actions/setup-python@v1"
         with:
           python-version: "3.9"
@@ -52,14 +56,26 @@ jobs:
           python -VV
           python -m pip install --upgrade pip
           pip install -r requirements_dev.txt
-          python -m pip install cumulusci
+          python -m pip install git+https://github.com/SFDO-Tooling/CumulusCI.git@main
 
       - name: Run Tests
-        run: python -m pytest
+        run: |
+          python -m coverage run -m pytest
+
+      - name: Check Coverage
+        run: |
+          coverage xml
+          coverage report
+          git diff HEAD.._remote_main_
+          diff-cover coverage.xml --fail-under 100 --compare-branch=_remote_main_ --diff-range-notation=.. --show-uncovered --markdown-report coverage.md
+          cat coverage.md >> $GITHUB_STEP_SUMMARY
+
+      - name: Type Check
+        run: pyright
 
   faker_docs:
     name: Faker Docs
-    runs-on: ubuntu-latest
+    runs-on: sfdc-ubuntu-latest
     steps:
       - uses: "actions/checkout@v2"
       - uses: "actions/setup-python@v1"
@@ -78,7 +94,7 @@ jobs:
 
   pip:
     name: "Install from Pip ${{ matrix.python-version }}"
-    runs-on: ubuntu-latest
+    runs-on: sfdc-ubuntu-latest
     strategy:
       matrix:
         python-version: ["3.8", "3.10"]
@@ -103,7 +119,7 @@ jobs:
 
   windows:
     name: Windows ${{ matrix.python-version }}
-    runs-on: windows-latest
+    runs-on: sfdc-windows-latest
     strategy:
       matrix:
         python-version: ["3.9", "3.10"]
@@ -125,6 +141,6 @@ jobs:
   coveralls_done:
     name: Finalize coveralls
     needs: [test]
-    runs-on: ubuntu-latest
+    runs-on: sfdc-ubuntu-latest
     steps:
       - run: curl -k https://coveralls.io/webhook?repo_token=$COVERALLS_REPO_TOKEN -d "payload[build_num]=$GITHUB_SHA&payload[status]=done"

.github/workflows/extra-checks-after-pull-request-review.yml

@@ -9,7 +9,7 @@ on:
 jobs:
   faker_docs:
     name: Faker Docs I18N
-    runs-on: ubuntu-latest
+    runs-on: sfdc-ubuntu-latest
     steps:
       - uses: "actions/checkout@v2"
       - uses: "actions/setup-python@v1"

.pre-commit-config.yaml

@@ -1,19 +1,19 @@
 default_language_version:
-    python: python3
+  python: python3
 repos:
--   repo: https://github.com/ambv/black
-    rev: 21.4b2
+  - repo: https://github.com/ambv/black
+    rev: 22.3.0
     hooks:
-    - id: black
--   repo: https://github.com/pre-commit/pre-commit-hooks
+      - id: black
+  - repo: https://github.com/pre-commit/pre-commit-hooks
     rev: v2.0.0
     hooks:
-    - id: check-merge-conflict
-    - id: flake8
-- repo: local
-  hooks:
-    - id: merge-docs
-      name: Merge examples into docs
-      entry: tools/docs_samples.py
-      language: python
-      files: ".*.md|examples/.*.yml"
+      - id: check-merge-conflict
+      - id: flake8
+  - repo: local
+    hooks:
+      - id: merge-docs
+        name: Merge examples into docs
+        entry: tools/docs_samples.py
+        language: python
+        files: ".*.md|examples/.*.yml"

HISTORY.md

@@ -4,6 +4,38 @@ In the beginning, programmers created the databases. Now the databases were form
 
 And so [Salesforce.org](http://salesforce.org/) said “Let there be data,” and there was Snowfakery. And it was good.
 
+## Snowfakery 3.5.0
+
+Snowfakery's Debug and CSV outputs now use the same format that Salesforce prefers. (#778)
+
+## Snowfakery 3.4.1
+
+Update dependencies.
+
+## Snowfakery 3.4
+
+Snowfakery can now generate Event or Meeting Schedules similar to Calendar Apps (#739)
+
+Snowfakery now has a `Salesforce.ContentFile` feature for generating Content Versions (#446)
+
+## Snowfakery 3.3
+
+Snowfakery has a `datetime_between` function (#779)
+
+Date-time values can now be coerced from strings and dates (#779)
+
+Fixes to documentation (thank you @BrettMN) (#727)
+
+`find_record` is now cached so that it only calls into Salesforce once. (#726)
+
+## Snowfakery 3.2
+
+Snowfakery can now do `random_reference` to nicknames. (#639)
+
+Removed some limitations on what Snowfakery can do with objects referenced through `random_reference`, especially using `a.b.c.d` syntax. (#681 and #639)
+
+Add a `unique` feature for `random_reference` (#684)
+
 ## Snowfakery 3.1
 
 When embedded in CumulusCI, Snowfakery can now do SObject Upserts. (#644)

README.md

@@ -1,4 +1,4 @@
-[![Coverage Status](https://coveralls.io/repos/github/SFDO-Tooling/Snowfakery/badge.svg?branch=master)](https://coveralls.io/github/SFDO-Tooling/Snowfakery?branch=master)
+[![Coverage Status](https://coveralls.io/repos/github/SFDO-Tooling/Snowfakery/badge.svg?branch=main)](https://coveralls.io/github/SFDO-Tooling/Snowfakery?branch=main)
 
 # Snowfakery Documentation
 

docs/adrs/0001-record-architecture-decisions.md

@@ -0,0 +1,67 @@
+---
+date: 2023-02-03
+status: Accepted
+author: @jstvz
+---
+
+# 1. Record architecture decisions
+
+## Context and Problem Statement
+
+We need to record the architectural decisions made on this project, but we lack a centralized location for storing them. This makes it difficult to find previous decisions. Moreover, we lack a shared vocabulary to discuss and a process to refine such decisions.
+
+### Assumptions
+
+1. A process for Requests for Comment exists in this repository or elsewhere.
+2. We define "architectural decision" as any software design choice that addresses a functional or non-functional requirement that is architecturally significant, for example:
+    - Which web framework to use
+    - Whether to denormalize a database table
+    - Whether or not to abandon a third-party test coverage aggregator
+
+## Decision
+
+### Options Considered
+
+1. Status Quo
+    1. Good: No changes to our process required
+    2. Bad: It can be difficult to find the reasons for our choices because there
+       are lots of places to look.
+2. Architectural Decision Records (ADRs)
+    1. Good: ADRs provide:
+        1. a centralized log of the decisions for our projects
+        2. a structured process for adopting decisions using pull requests
+        3. a lower barrier of entry for documenting a decision
+        4. a reference for teammates and community members
+        5. a shared understanding of a problem and its proposed solution
+        6. an ecosystem of existing tooling for managing and publishing ADRs
+    2. Bad:
+        1. Detailed discussions can expose spirited debates to public view
+        2. ADRs add a third place to search in addition to Quip and Confluence
+        3. ADRs add to the documentation burden
+
+### Decision Outcome
+
+We will use Architecture Decision Records, as [described at adr.github.io](https://adr.github.io/). This is a lightweight process is that is consistent with our existing code review workflow. Because these records are code, we can apply automation to lint files, automatically assign reviewers, and publish decisions to other repositories or the web.
+
+## Consequences
+
+We'll need additional discussions and RFCs to decide:
+
+1. the best way to organize the decision log,
+2. whether to retroactively record major decisions, or only future ones,
+3. whether to include decision records in our documentation.
+
+## References
+
+More information:
+
+-   [Decisions](https://atlas.sfdc.sh/decisions): Salesforce Architecture Library articles on RFCs and decision records.
+-   [ADR GitHub organization](https://adr.github.io/): References to more information on tooling and the reasons to adopt ADRs
+-   [Share the Load: Distribute Design Authority with Architecture Decision Records](https://www.agilealliance.org/resources/experience-reports/distribute-design-authority-with-architecture-decision-records): A case study about the adoption of ADRs by a microservices team at IBM.
+-   Zimmerman, et al., [_Architectural decision guidance across projects: problem space modeling, decision backlog management and cloud computing knowledge_](https://www.ifs.hsr.ch/fileadmin/user_upload/customers/ifs.hsr.ch/Home/projekte/ADMentor-WICSA2015ubmissionv11nc.pdf): Conference paper describing a theoretical framework for systematically reusing architectural knowledge across projects.
+
+Examples:
+
+-   [Timestamp format](https://github.com/joelparkerhenderson/architecture-decision-record/blob/main/examples/timestamp-format/index.md)
+-   [ADR process (internal Confluence)](https://confluence.internal.salesforce.com/pages/viewpage.action?pageId=349650878) Describes the ADR process for SFDC's Business Technology's Network Architecture team.
+-   [User Facing Configuration](https://github.com/arachne-framework/architecture/blob/master/adr-005-user-facing-config.md)

docs/adrs/README.md

@@ -0,0 +1,47 @@
+# Decision Records
+
+This directory contains the Architectural Decision Records (ADRs) for this project.
+
+## Architectural Decisions (ADs)
+
+We define "architectural decision" as any software design choice that addresses a functional or non-functional requirement that is architecturally significant, for example:
+
+-   Which web framework to use
+-   Whether to denormalize a database table
+-   Whether or not to abandon a third-party test coverage aggregator
+
+We store ADRs in the `docs/adrs` directory, named in this format: `000x-Title-of-ADR.md`.
+
+## Tools
+
+[`adr-tools`](https://github.com/npryce/adr-tools) is a simple CLI tool that manages ADRs. To install it via Homebrew:
+
+```shell
+brew install adr-tools
+```
+
+Create a new ADR
+
+```shell
+adr new Use FastDRF Library
+```
+
+which will create a new markdown document with the next number and open it for editing. To create a new decision record manually, simply copy the template at `templates/template.md` into this directory and name it appropriately.
+
+## Workflow
+
+1. Write an ADR outlining a decision for a particular problem.
+2. Create a pull request assigned to yourself and submit. If you know who will review your PR, you should request a review.[^1]
+3. The reviewer and other team members discuss the ADR. The ADR is updated during the review to add context, etc.
+4. At the end of the review period, the ADR is either:
+
+-   Approved: Status is "Accepted" and merge the PR, or
+-   Rejected: Update Status to "Rejected" and close the PR.
+
+5. Create a new ADR when reversing or revisiting a decision, linking to the decision record that it supercedes. Update the old ADR with a link to the superceding ADR.
+
+## Links
+
+-   [Suggestions for writing good ADRs](https://github.com/joelparkerhenderson/architecture-decision-record#suggestions-for-writing-good-adrs)
+
+[^1]: We encourage you to include your ADR in pull requests alongside related code changes when it makes sense to review them together.

docs/adrs/templates/template.md

@@ -0,0 +1,61 @@
+---
+date: DATE
+status: STATUS
+author: <!--@githubusername-->
+---
+
+<!--status: {proposed | rejected | accepted | deprecated | … | superseded by [ADR-0005](0005-example.md)}-->
+
+# NUMBER. TITLE
+
+## Context and Problem Statement
+
+Short description of issue motivating this decision, and any context that influences or constrains the decision. Can be framed as the first and third parts of a Y-Statement.
+
+<!--Optional sections-->
+
+### Assumptions
+
+Explicit assumptions made about the environment or requirements.
+
+### Constraints
+
+Explicit constraints imposed on the solution space.
+
+<!--Optional sections END-->
+
+## Decision
+
+### Considered Options
+
+1. Option 1
+    1. Good because reasons
+    1. Bad because reasons
+1. Option 2
+    1. Good because reasons
+    1. Bad because reasons
+1. Option $$n$$
+
+### Decision Outcome
+
+The Option that we're proposing or have agreed to implement, because of justification x...
+
+## Consequences
+
+What becomes easier or more difficult to do and any risks introduced by the change that will need to be mitigated.
+
+## References
+
+Links to related decisions, design artifacts or policies that affected the decision.
+
+-   Reference 1: Library documentation
+-   Reference 2: RFC describing implementation in detail
+-   Reference 3: ADR-0000
+
+<!--Optional sections-->
+
+## Notes
+
+Notes and issues captured from team discussions.
+
+<!--Optional sections END-->