update docs for new builtin data source

content/docs/tech-insights/enforce-branch-protection/index.md

@@ -6,6 +6,7 @@ description: How to enforce GitHub branch protection on production software with
 
 Branch protection can bring an extra layer of security to your organization by ensuring that code must be reviewed and tested before being merged. With Tech Insights, you can ensure teams are using branch protection on their software.
 
+Roadie automatically collects this information and you can view reports or create checks about that data.
 In this tutorial, we’re going to:
 
 1. Automatically scan Components in the Backstage catalog and record whether or not features like branch protection and required reviews are turned on or off for their GitHub repositories.
@@ -17,65 +18,11 @@ As we go through this process, you’ll learn how to create Data Sources that in
 
 1. You must have [installed the Roadie GitHub App](../../getting-started/install-github-app/).
 
-## Create a branch protection Data Source
-
-1. Visit Tech Insights and click into the Data Sources tab. Click the ADD DATA SOURCE button to create a new data source. 
-
-    ![a button on a web interface](../track-docker-base-image-migration/add-ds-button.png)
-
-2. Name the Data Source “GitHub branch protection” and give it the description “Detects if branch protection is turned on for the main branch of a repository.”
-
-    ![about.png](./about.png)
-
-3. In the Data Provider section, select the **"HTTP via Integration"** type and enter the Path Extension
-
-    ```
-    repos/{{ metadata.annotations["github.com/project-slug"] }}/branches/main/protection
-    ```
-    
-4. In the input labelled “Select Entity to test data source against”, choose an Entity in the catalog that has the `github.com/project-slug` annotation set, and has branch protection turned on for the repository the annotation points at. Click the VIEW button and you should see a response from the GitHub API.
-    
-    ![github-response.png](./github-response.png)
-    
-5. In the field extraction box, fill out the inputs with the following values.
-    
-    
-    | Fact name | JSONata query | Type |
-    | --- | --- | --- |
-    | Is branch protected | $exists(url) | Boolean |
-    | Enforce admins enabled | enforce_admins.enabled | Boolean |
-    | Linear history required enabled | required_linear_history.enabled | Boolean |
-    | Allow force pushes enabled | allow_force_pushes.enabled | Boolean |
-    | Allow deletions enabled | allow_deletions.enabled | Boolean |
-    | Block creations enabled | block_creations.enabled | Boolean |
-    | Required signatures enabled | required_signatures.enabled | Boolean |
-    | Dismiss stale reviews | required_pull_request_reviews.dismiss_stale_reviews | Boolean |
-    | Require code owner reviews | required_pull_request_reviews.require_code_owner_reviews | Boolean |
-    | Require last push approval | required_pull_request_reviews.require_last_push_approval | Boolean |
-    | Required approving review count | required_pull_request_reviews.required_approving_review_count | Integer |
-    | Strict required status checks | required_status_checks.strict | Boolean |
-
-6. Click the CHECK FACTS button and you should see that the facts are successfully extracted from the test response.
-    
-    ![extraction.png](./extraction.png)
-    
-7. In the “Applies to” section, set the following filters:
-    
-    
-    | Type | Component |
-    | --- | --- |
-    | Lifecycle | Production |
-    | Has Annotation | github.com/project-slug |
-
-8. Save the Data Source. After a minute or two, you should see results start to come in.
-    
-    ![ds-results.png](./ds-results.png)
-    
-
 ## Visualise the percentage of Components with branch protection
 
-Roadie Data Sources comes with a built-in visualization panel which lets us get an overview of the Dockerfile base image versions being used. When viewing a Data Source, expand the “Facts visualization” section to see it.
+In order to view the data, you can click Tech Insights > Data Sources > GitHub Settings Data Source
 
+You can then expand the "Fact Visualization" section and select the item that you want to view across your GitHub repositories.
 ![viz.png](./viz.png)
 
 This chart tells us that 81% of Components have branch protection turned on in their repositories.

content/docs/tech-insights/track-codeowners-usage/index.md

@@ -12,57 +12,8 @@ In this tutorial, we’re going to create a Tech Insights check that tracks adop
 
 1. You must have [intalled the Roadie GitHub App](../../getting-started/install-github-app/).
 
-## Create a CODEOWNERS Data Source
-
-
-
-1. Visit Tech Insights and click into the Data Sources tab. Click the ADD DATA SOURCE button to create a new data source.
-
-    ![a button on a web interface](../track-docker-base-image-migration/add-ds-button.png)
-
-2. Name the Data Source “CODEOWNERS” and give it the description “Detects usage and validity of the codeowners file in a repo.”
-
-    ![about.png](./about.png)
-
-3. In the Data Provider section, select the **"HTTP via Integration"** type and enter the Path Extension
-
-    ```
-    repos/{{ metadata.annotations["github.com/project-slug"] }}/codeowners/errors
-    ```
-    
-4. In the input labelled “Select Entity to test data source against”, choose an Entity in the catalog that has the `github.com/project-slug` annotation set, and has a valid CODEOWNERS file the repository the annotation points at. Click the VIEW button and you should see a response from the GitHub API.
-    
-    ![response.png](./response.png)
-    
-5. In the field extraction box, fill out the inputs with the following values.
-    
-    
-    | Fact name | JSONata query | Type |
-    | --- | --- | --- |
-    | Error count | $count(errors) | Integer |
-    | Has errors | $count(errors) != 0 | Boolean |
-    | Uses codeowners | $exists(errors) | Boolean |
-
-6. Click the CHECK FACTS button and you should see that the facts are successfully extracted from the test response.
-    
-    ![extraction.png](./extraction.png)
-    
-7. In the “Applies to” section, set the following filters:
-    
-    | Filter name | Value |
-    | --- | --- |
-    | Type | Component |
-    | Has Annotation | github.com/project-slug |
-
-8. Save the Data Source. After a minute or two, you should see results come in.
-    
-    ![results.png](./results.png)
-    
-
 ## Create a CODEOWNERS check
 
-Now that we can gather information about how CODEOWNERS is being used, we can write a check to figure out which components are using it correctly.
-
 1. Visit Tech Insights and click into the Checks tab. Click the ADD CHECK button to create a new check.
 
     ![](../track-docker-base-image-migration/add-check-button.png)
@@ -78,7 +29,7 @@ Now that we can gather information about how CODEOWNERS is being used, we can wr
 
     | Input name | Value |
     | --- | --- |
-    | Data Source | CODEOWNERS |
+    | Data Source | GitHub Settings Data Source |
     | Fact | Uses codeowners |
     | Fact operator | Is True |
 
@@ -87,15 +38,15 @@ Now that we can gather information about how CODEOWNERS is being used, we can wr
 
     | Input name | Value |
     | --- | --- |
-    | Data Source | CODEOWNERS |
-    | Fact | Has errors |
+    | Data Source | GitHub Settings Data Source |
+    | Fact | Codeowners Has Errors |
     | Fact operator | Is False |
 
     We now have a set of conditions which pass when a Component has a valid CODEOWNERS file, and fail otherwise.
 
     You can use the “DRY RUN” button to test these conditions against some Components in your catalog, ensure they operate the way you would expect, and return the correct pass or fail result.
 
-    ![compoind-conditions.png](./compoind-conditions.png)
+    ![compound-conditions.png](compound-conditions.png)
 
 7. Use the filters to target this check at production Components. You likely don't want to require random experimental repos to have CODEOWNERS files.
 8. Save the check by clicking “SAVE”. If you’re not quite ready to go live yet, you can use the “SAVE AS DRAFT” button to save the check but ensure only admins can see it.