Re-ran prettier on README.md

jongpie · Oct 16, 2024 · 68c4187 · 68c4187
1 parent 5453428
commit 68c4187
Show file tree

Hide file tree

Showing 2 changed files with 26 additions and 26 deletions.
diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml
@@ -180,7 +180,7 @@ jobs:
       # Nebula Logger has functionality that queries the AuthSession object when the current user has an active session.
       # The code should work with or without an active session, so the pipeline runs the tests twice - asynchronously and synchronously.
       # This is done because, based on how you execute Apex tests, the running user may have an active session (synchrously) or not (asynchronously).
-      # Utlimately, this could/should probably be better mocked during tests, but the AuthSession is read-only in Apex, so it's a bit difficult to work with.
+      # Ultimately, this could/should probably be better mocked during tests, but the AuthSession is read-only in Apex, so it's a bit difficult to work with.
       # Running the Apex tests sync & async serves as an extra level of integration testing to ensure that everything works with or without an active session.
       - name: 'Run Apex Tests Asynchronously'
         run: npm run test:apex:nocoverage
@@ -256,7 +256,7 @@ jobs:
       # Nebula Logger has functionality that queries the AuthSession object when the current user has an active session.
       # The code should work with or without an active session, so the pipeline runs the tests twice - asynchronously and synchronously.
       # This is done because, based on how you execute Apex tests, the running user may have an active session (synchrously) or not (asynchronously).
-      # Utlimately, this could/should probably be better mocked during tests, but the AuthSession is read-only in Apex, so it's a bit difficult to work with.
+      # Ultimately, this could/should probably be better mocked during tests, but the AuthSession is read-only in Apex, so it's a bit difficult to work with.
       # Running the Apex tests sync & async serves as an extra level of integration testing to ensure that everything works with or without an active session.
       - name: 'Run Apex Tests Asynchronously'
         run: npm run test:apex:nocoverage
@@ -324,7 +324,7 @@ jobs:
       # Nebula Logger has functionality that queries the AuthSession object when the current user has an active session.
       # The code should work with or without an active session, so the pipeline runs the tests twice - asynchronously and synchronously.
       # This is done because, based on how you execute Apex tests, the running user may have an active session (synchrously) or not (asynchronously).
-      # Utlimately, this could/should probably be better mocked during tests, but the AuthSession is read-only in Apex, so it's a bit difficult to work with.
+      # Ultimately, this could/should probably be better mocked during tests, but the AuthSession is read-only in Apex, so it's a bit difficult to work with.
       # Running the Apex tests sync & async serves as an extra level of integration testing to ensure that everything works with or without an active session.
       - name: 'Run Apex Tests Asynchronously'
         run: npm run test:apex:nocoverage
@@ -395,7 +395,7 @@ jobs:
       # Nebula Logger has functionality that queries the AuthSession object when the current user has an active session.
       # The code should work with or without an active session, so the pipeline runs the tests twice - asynchronously and synchronously.
       # This is done because, based on how you execute Apex tests, the running user may have an active session (synchrously) or not (asynchronously).
-      # Utlimately, this could/should probably be better mocked during tests, but the AuthSession is read-only in Apex, so it's a bit difficult to work with.
+      # Ultimately, this could/should probably be better mocked during tests, but the AuthSession is read-only in Apex, so it's a bit difficult to work with.
       # Running the Apex tests sync & async serves as an extra level of integration testing to ensure that everything works with or without an active session.
       - name: 'Run Apex Tests Asynchronously'
         run: npm run test:apex:nocoverage
@@ -470,7 +470,7 @@ jobs:
       # Nebula Logger has functionality that queries the AuthSession object when the current user has an active session.
       # The code should work with or without an active session, so the pipeline runs the tests twice - asynchronously and synchronously.
       # This is done because, based on how you execute Apex tests, the running user may have an active session (synchrously) or not (asynchronously).
-      # Utlimately, this could/should probably be better mocked during tests, but the AuthSession is read-only in Apex, so it's a bit difficult to work with.
+      # Ultimately, this could/should probably be better mocked during tests, but the AuthSession is read-only in Apex, so it's a bit difficult to work with.
       # Running the Apex tests sync & async serves as an extra level of integration testing to ensure that everything works with or without an active session.
       - name: 'Run Apex Tests Asynchronously'
         run: npm run test:apex:nocoverage
@@ -538,7 +538,7 @@ jobs:
       # Nebula Logger has functionality that queries the AuthSession object when the current user has an active session.
       # The code should work with or without an active session, so the pipeline runs the tests twice - asynchronously and synchronously.
       # This is done because, based on how you execute Apex tests, the running user may have an active session (synchrously) or not (asynchronously).
-      # Utlimately, this could/should probably be better mocked during tests, but the AuthSession is read-only in Apex, so it's a bit difficult to work with.
+      # Ultimately, this could/should probably be better mocked during tests, but the AuthSession is read-only in Apex, so it's a bit difficult to work with.
       # Running the Apex tests sync & async serves as an extra level of integration testing to ensure that everything works with or without an active session.
       - name: 'Run Apex Tests Asynchronously'
         run: npm run test:apex:nocoverage
@@ -653,7 +653,7 @@ jobs:
       # Nebula Logger has functionality that queries the AuthSession object when the current user has an active session.
       # The code should work with or without an active session, so the pipeline runs the tests twice - asynchronously and synchronously.
       # This is done because, based on how you execute Apex tests, the running user may have an active session (synchrously) or not (asynchronously).
-      # Utlimately, this could/should probably be better mocked during tests, but the AuthSession is read-only in Apex, so it's a bit difficult to work with.
+      # Ultimately, this could/should probably be better mocked during tests, but the AuthSession is read-only in Apex, so it's a bit difficult to work with.
       # Running the Apex tests sync & async serves as an extra level of integration testing in the meantime to ensure that everything works with or without an active session.
       - name: 'Run Apex Tests Asynchronously'
         run: npm run test:apex:nocoverage -- --targetusername nebula-logger-package-demo

diff --git a/README.md b/README.md
@@ -829,25 +829,25 @@ If you want to add your own automation to the `Log__c` or `LogEntry__c` objects,
 
   ```apex
   public class ExampleTriggerablePlugin implements LoggerPlugin.Triggerable {
-     public void execute(LoggerPlugin__mdt configuration, LoggerTriggerableContext input) {
-       // Example: only run the plugin for Log__c records
-       if (context.sobjectType != Schema.Log__c.SObjectType) {
-         return;
-       }
-    
-       List<Log__c> logs = (List<Log__c>) input.triggerNew;
-       switch on input.triggerOperationType {
-         when BEFORE_INSERT {
-           for (Log__c log : logs) {
-             log.Status__c = 'On Hold';
-           }
-         }
-         when BEFORE_UPDATE{
-           // TODO add before-update logic
-         }
-       }
-     }
-   }
+    public void execute(LoggerPlugin__mdt configuration, LoggerTriggerableContext input) {
+      // Example: only run the plugin for Log__c records
+      if (context.sobjectType != Schema.Log__c.SObjectType) {
+        return;
+      }
+
+      List<Log__c> logs = (List<Log__c>) input.triggerNew;
+      switch on input.triggerOperationType {
+        when BEFORE_INSERT {
+          for (Log__c log : logs) {
+            log.Status__c = 'On Hold';
+          }
+        }
+        when BEFORE_UPDATE {
+          // TODO add before-update logic
+        }
+      }
+    }
+  }
   ```
 
 Once you've created your Apex or Flow plugin(s), you will also need to configure the plugin: