From d0fc372efb524cc627fde6768380acb0f051e8fa Mon Sep 17 00:00:00 2001 From: Quarto GHA Workflow Runner Date: Tue, 25 Jun 2024 22:40:00 +0000 Subject: [PATCH] Built site for gh-pages --- .nojekyll | 2 +- part2-github.html | 74 ++++++++++++++++++++++------------------------- search.json | 16 ++-------- sitemap.xml | 12 ++++---- 4 files changed, 45 insertions(+), 59 deletions(-) diff --git a/.nojekyll b/.nojekyll index 1b4dbdd..59c6913 100644 --- a/.nojekyll +++ b/.nojekyll @@ -1 +1 @@ -94e69eba \ No newline at end of file +1b310294 \ No newline at end of file diff --git a/part2-github.html b/part2-github.html index 0d7db14..da5ce96 100644 --- a/part2-github.html +++ b/part2-github.html @@ -163,8 +163,7 @@

On this page

@@ -211,44 +210,39 @@

Part 2: GitHub workflow

Workflow to contribute via GitHub

-

Bold words are git/GitHub terms

+

Bold words are git/GitHub terms. In this example there are two roles: an Author and a Reviewer.

    -
  1. Inspect the differences your edits will introduce
    2. -
  2. Stage your changes
    3. -
  3. Commit your changes with a helpful Commit message
    4. -
  4. Push to GitHub
    5. -
  5. Go to the Clinic repo source on GitHub, in your browser
    6. -
  6. Make a Pull Request and tag a reviewer
    7. +
  7. Author stages their changes
    8. +
  8. Author commits changes with a helpful Commit message
    9. +
  9. Author pushes to GitHub
    10. +
  10. Author make a Pull Request and tag a reviewer from GitHub.com
  11. Reviewer responds by commenting, making suggested commits, and submitting their review
  12. Author responds to review and merges their Pull Request
  13. A GitHub Action automatically publishes the updates in the live siteDiff, Stage, Commit, and Push your edits to GitHub
-
-
-

Contribute your updates using GitHub

Now that we have each saved some changes to files in our Quarto site source, we can contribute our updates using GitHub.

We will demonstrate this and then you will do this in breakout rooms.

Author stages, commits, and pushes file

-

You have to deliberately tell Git/GitHub when you have work that you want to be versioned and synced. First, inspect the differences your edits will introduce.

+

We have to deliberately tell Git/GitHub when you have work that we want to be versioned and synced. This is separate from saving the file, which is required first. Let’s inspect the differences our edits will introduce.

-

In the Git tab “stage” your saved changes. There may be a .json file that you also stage; this is part of the Quarto build process.

+

In the Git tab I will “stage” my saved changes. (There may be a .json file that you also stage; this is part of the Quarto build process.)

Stage your changes
-

Commit your edits with a good commit message and push your edits to GitHub. A commit message is a human-readable message, like leaving a breadcrumb trail for your future self and others.

-

Commit and Push When you push by clicking the push icon (with the orange dot since we have committed files to push), you may be prompted to enter your git credentials.

+

Next I will commit my edits with a good commit message and push my edits to GitHub. A commit message is a human-readable message, like leaving a breadcrumb trail for my future self and others.

+

Commit and Push When we push by clicking the push icon (with the orange dot since we have committed files to push), we may be prompted to enter git credentials.

Aside: set up our Git credentials

-

On your first commit, you will be prompted to add your Git credentials. When you are working on a project over time, you can have them stored, following instructions in Configure Git (git config) from the 2021 Cloud Hackathon.

+

You will be prompted to add your Git credentials. When you are working on a project over time, you can have them stored, following instructions in Configure Git (git config) from the 2021 Cloud Hackathon.

TODO: do we need to do Step 5.1. Configure Git (git config)? (but ignore the push file part). Clarify the following text to say see the orange dot. click it to be prompted

When you see the following screenshot, GitHub is asking for you to input your credentials. (Note: you see this screenshot when you have committed work to push to GitHub.com. In this case we have created a new branch in the Hub and it does not yet exist on GitHub.

@@ -261,26 +255,23 @@

Aside: se

Author makes a Pull Request

-

Our current status is that in the Hub, in our own branch of the Quarto Clinic repo, we have made one or more edits to the Clinic files, committed those updates, and pushed those commit(s) to GitHub. How do our suggested contributions get incorporated into the main Quarto Clinic repo and website? Via a Pull Request.

-

Now we’ll go to https://github.com/Openscapes/quarto-clinic/ and you will see a yellow banner inviting you to make a Pull Request to add your edits to the Clinic repo.

+

Our current status: We are in the Hub, and in our own branch of the Quarto Clinic GitHub repo, we have made one or more edits to the Clinic files, committed those updates, and pushed those commit(s) to GitHub. How do our suggested contributions get incorporated into the main Quarto Clinic repo and website? Via a GitHub Pull Request.

+

So now I’ll go to https://github.com/NASA-Openscapes/quarto-clinic/ and I will see a yellow banner inviting me to make a Pull Request to add my edits to the Clinic repo.

-

Not finished proposing your updates? You can set your Pull Request as a Draft at the start so folks can see your thinking. Set Ready for Review when ready and request a reviewer(s). For the NASA Earthdata Cloud Cookbook, any Pull Request must be reviewed before it can be merged. If you know someone who is familiar with the content you’re proposing to add, request their review.

+

Maybe I’m not finished proposing my updates? I can set my Pull Request as a Draft at the start so folks can see my thinking, and we can have conversations about it. Set Ready for Review when ready and request a reviewer(s). For the NASA Earthdata Cloud Cookbook, any Pull Request must be reviewed before it can be merged. If you know someone who is familiar with the content you’re proposing to add, request their review.

+
+

Pull Request elements

First view of a Pull Request.
-
-
-

Reviewer reviews the Pull Request

-

TODO:

From the pull request page in GitHub browser, look at the elements of the pull request.

-
  • Start with Conversation tab:
      @@ -301,16 +292,11 @@

      Reviewer
    • Shows status of the Github Action that renders and deploys the site. We can know whether this Pull Request is able to be deployed.

-

Now, switch to the 2i2c Hub to view the Clinic preview as it would appear if the pull request was merged:

-
    -
  • Terminal: -
      -
    • Go to the Main branch and pull so that we have the most recent changes from remote.
      • -
    • git checkout to the branch that has the Pull Request
      • -
    • quarto preview - this will build the book with the author’s suggested edits.
      • -
    • -
-

In reviewing a pull request with lots of changes, it can be helpful to have windows open to view both the GitHub browser and the 2i2c Hub showing the Clinic site preview.

+
+
+
+

Reviewer reviews the Pull Request

+

GitHub has gotten really powerful at doing reviews from the browser, so we can review small Pull Requests right here in GitHub.com. Note: When you are reviewing a Pull Request with a lot of code and analyses you need to run and dig into more deeply, you will do your review in JupyterHub by pulling the branch’s updates and committing your suggestions there. Today we will only practice a small review from the GitHub browser.

  • In GitHub under the “Files changed” tab of the PR, we can add a suggested edit by clicking the “plus” button below the line in question. Suggesting specific commits can speed the contributor’s workflow compared with trying to describe what we’d like them to change.
  • We can click “Start a review” button so the author gets a single email when we’re done reviewing, rather than getting one notification for every edit we suggest.
    • @@ -351,9 +337,6 @@

    Tidying up

Regroup discussion topics

-
-

Deleting branches

-

Code & rendering .qmd files

You can add code TODO

@@ -361,6 +344,19 @@

Code & rende

TODO: day before clinic, make this Python code (don’t add screenshot - fewer files to for folks to get distracted with, lighter weight repo)

You can add options to executable code. The echo: false option disables the printing of code (only output is displayed).

+
+

Review in JupyterHub

+

Now, switch to the 2i2c Hub to view the Clinic preview as it would appear if the pull request was merged:

+
    +
  • Terminal: +
      +
    • Go to the Main branch and pull so that we have the most recent changes from remote.
      • +
    • git checkout to the branch that has the Pull Request
      • +
    • quarto preview - this will build the book with the author’s suggested edits.
      • +
    • +
+

In reviewing a pull request with lots of changes, it can be helpful to have windows open to view both the GitHub browser and the 2i2c Hub showing the Clinic site preview.

+

Freeze

Commit the freeze folder.

diff --git a/search.json b/search.json index 8621283..befb2ab 100644 --- a/search.json +++ b/search.json @@ -94,7 +94,7 @@ "href": "part2-github.html", "title": "Part 2: GitHub workflow", "section": "", - "text": "Bold words are git/GitHub terms\n\nInspect the differences your edits will introduce\nStage your changes\nCommit your changes with a helpful Commit message\nPush to GitHub\nGo to the Clinic repo source on GitHub, in your browser\nMake a Pull Request and tag a reviewer\nReviewer responds by commenting, making suggested commits, and submitting their review\nAuthor responds to review and merges their Pull Request\nA GitHub Action automatically publishes the updates in the live siteDiff, Stage, Commit, and Push your edits to GitHub", + "text": "Bold words are git/GitHub terms. In this example there are two roles: an Author and a Reviewer.\n\nAuthor stages their changes\nAuthor commits changes with a helpful Commit message\nAuthor pushes to GitHub\nAuthor make a Pull Request and tag a reviewer from GitHub.com\nReviewer responds by commenting, making suggested commits, and submitting their review\nAuthor responds to review and merges their Pull Request\nA GitHub Action automatically publishes the updates in the live siteDiff, Stage, Commit, and Push your edits to GitHub\n\nNow that we have each saved some changes to files in our Quarto site source, we can contribute our updates using GitHub.\nWe will demonstrate this and then you will do this in breakout rooms.\n\n\nWe have to deliberately tell Git/GitHub when you have work that we want to be versioned and synced. This is separate from saving the file, which is required first. Let’s inspect the differences our edits will introduce.\n\n\n\n\n\nIn the Git tab I will “stage” my saved changes. (There may be a .json file that you also stage; this is part of the Quarto build process.)\n\n\n\nStage your changes\n\n\nNext I will commit my edits with a good commit message and push my edits to GitHub. A commit message is a human-readable message, like leaving a breadcrumb trail for my future self and others.\n When we push by clicking the push icon (with the orange dot since we have committed files to push), we may be prompted to enter git credentials.\n\n\n\nYou will be prompted to add your Git credentials. When you are working on a project over time, you can have them stored, following instructions in Configure Git (git config) from the 2021 Cloud Hackathon.\nTODO: do we need to do Step 5.1. Configure Git (git config)? (but ignore the push file part). Clarify the following text to say see the orange dot. click it to be prompted\nWhen you see the following screenshot, GitHub is asking for you to input your credentials. (Note: you see this screenshot when you have committed work to push to GitHub.com. In this case we have created a new branch in the Hub and it does not yet exist on GitHub.\n\n\n\nPrompt to add your Git credentials\n\n\nWe’ll follow the instructions in the 2021 Cloud Hackathon to Setup your Personal Access Token (PAT).\n\n\n\nOur current status: We are in the Hub, and in our own branch of the Quarto Clinic GitHub repo, we have made one or more edits to the Clinic files, committed those updates, and pushed those commit(s) to GitHub. How do our suggested contributions get incorporated into the main Quarto Clinic repo and website? Via a GitHub Pull Request.\nSo now I’ll go to https://github.com/NASA-Openscapes/quarto-clinic/ and I will see a yellow banner inviting me to make a Pull Request to add my edits to the Clinic repo.\n\n\n\n\n\nMaybe I’m not finished proposing my updates? I can set my Pull Request as a Draft at the start so folks can see my thinking, and we can have conversations about it. Set Ready for Review when ready and request a reviewer(s). For the NASA Earthdata Cloud Cookbook, any Pull Request must be reviewed before it can be merged. If you know someone who is familiar with the content you’re proposing to add, request their review.\n\n\n\n\n\nFirst view of a Pull Request.\n\n\nFrom the pull request page in GitHub browser, look at the elements of the pull request.\n\nStart with Conversation tab:\n\nWe can see all commits and comments on what Andy has worked on\nThis is where we can add PR reviewers by clicking the gear icon next to “Reviewers” at the top right corner of this tab.\n\nCommit tab:\n\nMore details on the commits that we saw under Conversation. When we click on one of the commits, we can see line by line what has changed under that commit (green lines are added, red lines have been removed)\n\nFiles Changed tab:\n\nView all the files that changed across the commits\nIn Nav bar: Orange dot box signifies modified; Green plus box means something’s been added; Red minus box means deleted; Grey arrow box means renamed.\n\nChecks tab:\n\nShows status of the Github Action that renders and deploys the site. We can know whether this Pull Request is able to be deployed.\n\n\n\n\n\n\nGitHub has gotten really powerful at doing reviews from the browser, so we can review small Pull Requests right here in GitHub.com. Note: When you are reviewing a Pull Request with a lot of code and analyses you need to run and dig into more deeply, you will do your review in JupyterHub by pulling the branch’s updates and committing your suggestions there. Today we will only practice a small review from the GitHub browser.\n\nIn GitHub under the “Files changed” tab of the PR, we can add a suggested edit by clicking the “plus” button below the line in question. Suggesting specific commits can speed the contributor’s workflow compared with trying to describe what we’d like them to change.\nWe can click “Start a review” button so the author gets a single email when we’re done reviewing, rather than getting one notification for every edit we suggest.\n\nReview each individual file that has changed and come back to the main _quarto.yml if we see an issue with the navigation.\nOnce our review is complete, we add a note in the GitHub review box and click “Approve”, “Comment” or “Request changes”. In the note it can be really helpful to add a note of appreciation for some aspect of the contribution, tagging the author, saying they can merge the PR after making changes, and possibly add a summary of our requested edits including the number of changes requested. Some changes in the middle of a long list of edits can be marked as hidden conversations, so this can be helpful to the author to know they’ve seen everything.\n\n\n\nAs the author, you can now address the reviewer’s comments and then merge your Pull Request.", "crumbs": [ "Part 2: GitHub workflow" ] @@ -104,17 +104,7 @@ "href": "part2-github.html#workflow-to-contribute-via-github", "title": "Part 2: GitHub workflow", "section": "", - "text": "Bold words are git/GitHub terms\n\nInspect the differences your edits will introduce\nStage your changes\nCommit your changes with a helpful Commit message\nPush to GitHub\nGo to the Clinic repo source on GitHub, in your browser\nMake a Pull Request and tag a reviewer\nReviewer responds by commenting, making suggested commits, and submitting their review\nAuthor responds to review and merges their Pull Request\nA GitHub Action automatically publishes the updates in the live siteDiff, Stage, Commit, and Push your edits to GitHub", - "crumbs": [ - "Part 2: GitHub workflow" - ] - }, - { - "objectID": "part2-github.html#contribute-your-updates-using-github", - "href": "part2-github.html#contribute-your-updates-using-github", - "title": "Part 2: GitHub workflow", - "section": "Contribute your updates using GitHub", - "text": "Contribute your updates using GitHub\nNow that we have each saved some changes to files in our Quarto site source, we can contribute our updates using GitHub.\nWe will demonstrate this and then you will do this in breakout rooms.\n\nAuthor stages, commits, and pushes file\nYou have to deliberately tell Git/GitHub when you have work that you want to be versioned and synced. First, inspect the differences your edits will introduce.\n\n\n\n\n\nIn the Git tab “stage” your saved changes. There may be a .json file that you also stage; this is part of the Quarto build process.\n\n\n\nStage your changes\n\n\nCommit your edits with a good commit message and push your edits to GitHub. A commit message is a human-readable message, like leaving a breadcrumb trail for your future self and others.\n When you push by clicking the push icon (with the orange dot since we have committed files to push), you may be prompted to enter your git credentials.\n\n\nAside: set up our Git credentials\nOn your first commit, you will be prompted to add your Git credentials. When you are working on a project over time, you can have them stored, following instructions in Configure Git (git config) from the 2021 Cloud Hackathon.\nTODO: do we need to do Step 5.1. Configure Git (git config)? (but ignore the push file part). Clarify the following text to say see the orange dot. click it to be prompted\nWhen you see the following screenshot, GitHub is asking for you to input your credentials. (Note: you see this screenshot when you have committed work to push to GitHub.com. In this case we have created a new branch in the Hub and it does not yet exist on GitHub.\n\n\n\nPrompt to add your Git credentials\n\n\nWe’ll follow the instructions in the 2021 Cloud Hackathon to Setup your Personal Access Token (PAT).\n\n\nAuthor makes a Pull Request\nOur current status is that in the Hub, in our own branch of the Quarto Clinic repo, we have made one or more edits to the Clinic files, committed those updates, and pushed those commit(s) to GitHub. How do our suggested contributions get incorporated into the main Quarto Clinic repo and website? Via a Pull Request.\nNow we’ll go to https://github.com/Openscapes/quarto-clinic/ and you will see a yellow banner inviting you to make a Pull Request to add your edits to the Clinic repo.\n\n\n\n\n\nNot finished proposing your updates? You can set your Pull Request as a Draft at the start so folks can see your thinking. Set Ready for Review when ready and request a reviewer(s). For the NASA Earthdata Cloud Cookbook, any Pull Request must be reviewed before it can be merged. If you know someone who is familiar with the content you’re proposing to add, request their review.\n\n\n\nFirst view of a Pull Request.\n\n\n\n\nReviewer reviews the Pull Request\nTODO:\nFrom the pull request page in GitHub browser, look at the elements of the pull request.\n\n\nStart with Conversation tab:\n\nWe can see all commits and comments on what Andy has worked on\nThis is where we can add PR reviewers by clicking the gear icon next to “Reviewers” at the top right corner of this tab.\n\nCommit tab:\n\nMore details on the commits that we saw under Conversation. When we click on one of the commits, we can see line by line what has changed under that commit (green lines are added, red lines have been removed)\n\nFiles Changed tab:\n\nView all the files that changed across the commits\nIn Nav bar: Orange dot box signifies modified; Green plus box means something’s been added; Red minus box means deleted; Grey arrow box means renamed.\n\nChecks tab:\n\nShows status of the Github Action that renders and deploys the site. We can know whether this Pull Request is able to be deployed.\n\n\nNow, switch to the 2i2c Hub to view the Clinic preview as it would appear if the pull request was merged:\n\nTerminal:\n\nGo to the Main branch and pull so that we have the most recent changes from remote.\ngit checkout to the branch that has the Pull Request\nquarto preview - this will build the book with the author’s suggested edits.\n\n\nIn reviewing a pull request with lots of changes, it can be helpful to have windows open to view both the GitHub browser and the 2i2c Hub showing the Clinic site preview.\n\nIn GitHub under the “Files changed” tab of the PR, we can add a suggested edit by clicking the “plus” button below the line in question. Suggesting specific commits can speed the contributor’s workflow compared with trying to describe what we’d like them to change.\nWe can click “Start a review” button so the author gets a single email when we’re done reviewing, rather than getting one notification for every edit we suggest.\n\nReview each individual file that has changed and come back to the main _quarto.yml if we see an issue with the navigation.\nOnce our review is complete, we add a note in the GitHub review box and click “Approve”, “Comment” or “Request changes”. In the note it can be really helpful to add a note of appreciation for some aspect of the contribution, tagging the author, saying they can merge the PR after making changes, and possibly add a summary of our requested edits including the number of changes requested. Some changes in the middle of a long list of edits can be marked as hidden conversations, so this can be helpful to the author to know they’ve seen everything.\n\n\nAuthor merges Pull Request\nAs the author, you can now address the reviewer’s comments and then merge your Pull Request.", + "text": "Bold words are git/GitHub terms. In this example there are two roles: an Author and a Reviewer.\n\nAuthor stages their changes\nAuthor commits changes with a helpful Commit message\nAuthor pushes to GitHub\nAuthor make a Pull Request and tag a reviewer from GitHub.com\nReviewer responds by commenting, making suggested commits, and submitting their review\nAuthor responds to review and merges their Pull Request\nA GitHub Action automatically publishes the updates in the live siteDiff, Stage, Commit, and Push your edits to GitHub\n\nNow that we have each saved some changes to files in our Quarto site source, we can contribute our updates using GitHub.\nWe will demonstrate this and then you will do this in breakout rooms.\n\n\nWe have to deliberately tell Git/GitHub when you have work that we want to be versioned and synced. This is separate from saving the file, which is required first. Let’s inspect the differences our edits will introduce.\n\n\n\n\n\nIn the Git tab I will “stage” my saved changes. (There may be a .json file that you also stage; this is part of the Quarto build process.)\n\n\n\nStage your changes\n\n\nNext I will commit my edits with a good commit message and push my edits to GitHub. A commit message is a human-readable message, like leaving a breadcrumb trail for my future self and others.\n When we push by clicking the push icon (with the orange dot since we have committed files to push), we may be prompted to enter git credentials.\n\n\n\nYou will be prompted to add your Git credentials. When you are working on a project over time, you can have them stored, following instructions in Configure Git (git config) from the 2021 Cloud Hackathon.\nTODO: do we need to do Step 5.1. Configure Git (git config)? (but ignore the push file part). Clarify the following text to say see the orange dot. click it to be prompted\nWhen you see the following screenshot, GitHub is asking for you to input your credentials. (Note: you see this screenshot when you have committed work to push to GitHub.com. In this case we have created a new branch in the Hub and it does not yet exist on GitHub.\n\n\n\nPrompt to add your Git credentials\n\n\nWe’ll follow the instructions in the 2021 Cloud Hackathon to Setup your Personal Access Token (PAT).\n\n\n\nOur current status: We are in the Hub, and in our own branch of the Quarto Clinic GitHub repo, we have made one or more edits to the Clinic files, committed those updates, and pushed those commit(s) to GitHub. How do our suggested contributions get incorporated into the main Quarto Clinic repo and website? Via a GitHub Pull Request.\nSo now I’ll go to https://github.com/NASA-Openscapes/quarto-clinic/ and I will see a yellow banner inviting me to make a Pull Request to add my edits to the Clinic repo.\n\n\n\n\n\nMaybe I’m not finished proposing my updates? I can set my Pull Request as a Draft at the start so folks can see my thinking, and we can have conversations about it. Set Ready for Review when ready and request a reviewer(s). For the NASA Earthdata Cloud Cookbook, any Pull Request must be reviewed before it can be merged. If you know someone who is familiar with the content you’re proposing to add, request their review.\n\n\n\n\n\nFirst view of a Pull Request.\n\n\nFrom the pull request page in GitHub browser, look at the elements of the pull request.\n\nStart with Conversation tab:\n\nWe can see all commits and comments on what Andy has worked on\nThis is where we can add PR reviewers by clicking the gear icon next to “Reviewers” at the top right corner of this tab.\n\nCommit tab:\n\nMore details on the commits that we saw under Conversation. When we click on one of the commits, we can see line by line what has changed under that commit (green lines are added, red lines have been removed)\n\nFiles Changed tab:\n\nView all the files that changed across the commits\nIn Nav bar: Orange dot box signifies modified; Green plus box means something’s been added; Red minus box means deleted; Grey arrow box means renamed.\n\nChecks tab:\n\nShows status of the Github Action that renders and deploys the site. We can know whether this Pull Request is able to be deployed.\n\n\n\n\n\n\nGitHub has gotten really powerful at doing reviews from the browser, so we can review small Pull Requests right here in GitHub.com. Note: When you are reviewing a Pull Request with a lot of code and analyses you need to run and dig into more deeply, you will do your review in JupyterHub by pulling the branch’s updates and committing your suggestions there. Today we will only practice a small review from the GitHub browser.\n\nIn GitHub under the “Files changed” tab of the PR, we can add a suggested edit by clicking the “plus” button below the line in question. Suggesting specific commits can speed the contributor’s workflow compared with trying to describe what we’d like them to change.\nWe can click “Start a review” button so the author gets a single email when we’re done reviewing, rather than getting one notification for every edit we suggest.\n\nReview each individual file that has changed and come back to the main _quarto.yml if we see an issue with the navigation.\nOnce our review is complete, we add a note in the GitHub review box and click “Approve”, “Comment” or “Request changes”. In the note it can be really helpful to add a note of appreciation for some aspect of the contribution, tagging the author, saying they can merge the PR after making changes, and possibly add a summary of our requested edits including the number of changes requested. Some changes in the middle of a long list of edits can be marked as hidden conversations, so this can be helpful to the author to know they’ve seen everything.\n\n\n\nAs the author, you can now address the reviewer’s comments and then merge your Pull Request.", "crumbs": [ "Part 2: GitHub workflow" ] @@ -144,7 +134,7 @@ "href": "part2-github.html#regroup-discussion-topics", "title": "Part 2: GitHub workflow", "section": "Regroup discussion topics", - "text": "Regroup discussion topics\n\nDeleting branches\n\n\nCode & rendering .qmd files\nYou can add code TODO\nWhen you Render, a document will be generated that includes both content and the output of embedded code. You can embed code like this:\nTODO: day before clinic, make this Python code (don’t add screenshot - fewer files to for folks to get distracted with, lighter weight repo)\nYou can add options to executable code. The echo: false option disables the printing of code (only output is displayed).\n\n\nFreeze\nCommit the freeze folder.\n\nFreeze directory contains the results of code execution.\nCommit the freeze directory after you run quarto preview.\nIf there are merge conflicts when you submit to NASA Openscapes Cookbook, maintainers will help resolve them.", + "text": "Regroup discussion topics\n\nCode & rendering .qmd files\nYou can add code TODO\nWhen you Render, a document will be generated that includes both content and the output of embedded code. You can embed code like this:\nTODO: day before clinic, make this Python code (don’t add screenshot - fewer files to for folks to get distracted with, lighter weight repo)\nYou can add options to executable code. The echo: false option disables the printing of code (only output is displayed).\n\n\nReview in JupyterHub\nNow, switch to the 2i2c Hub to view the Clinic preview as it would appear if the pull request was merged:\n\nTerminal:\n\nGo to the Main branch and pull so that we have the most recent changes from remote.\ngit checkout to the branch that has the Pull Request\nquarto preview - this will build the book with the author’s suggested edits.\n\n\nIn reviewing a pull request with lots of changes, it can be helpful to have windows open to view both the GitHub browser and the 2i2c Hub showing the Clinic site preview.\n\n\nFreeze\nCommit the freeze folder.\n\nFreeze directory contains the results of code execution.\nCommit the freeze directory after you run quarto preview.\nIf there are merge conflicts when you submit to NASA Openscapes Cookbook, maintainers will help resolve them.", "crumbs": [ "Part 2: GitHub workflow" ] diff --git a/sitemap.xml b/sitemap.xml index 4cea4fb..eac1c18 100644 --- a/sitemap.xml +++ b/sitemap.xml @@ -2,26 +2,26 @@ https://openscapes.github.io/quarto-clinic/part0-setup.html - 2024-06-25T22:28:34.791Z + 2024-06-25T22:39:17.931Z https://openscapes.github.io/quarto-clinic/next-steps.html - 2024-06-25T22:28:34.791Z + 2024-06-25T22:39:17.931Z https://openscapes.github.io/quarto-clinic/part2-github.html - 2024-06-25T22:28:34.791Z + 2024-06-25T22:39:17.931Z https://openscapes.github.io/quarto-clinic/part1-quarto.html - 2024-06-25T22:28:34.791Z + 2024-06-25T22:39:17.931Z https://openscapes.github.io/quarto-clinic/demo.html - 2024-06-25T22:28:34.727Z + 2024-06-25T22:39:17.867Z https://openscapes.github.io/quarto-clinic/index.html - 2024-06-25T22:28:34.791Z + 2024-06-25T22:39:17.927Z