updating content files

Author: gracepark

content/actions/creating-actions/about-actions.md

@@ -21,7 +21,7 @@ topics:
 {% data reusables.actions.enterprise-github-hosted-runners %}
 {% data reusables.actions.ae-beta %}
 
-### About actions
+## About actions
 
 You can create actions by writing custom code that interacts with your repository in any way you'd like, including integrating with {% data variables.product.prodname_dotcom %}'s APIs and any publicly available third-party API. For example, an action can publish npm modules, send SMS alerts when urgent issues are created, or deploy production-ready code.
 
@@ -31,7 +31,7 @@ You can write your own actions to use in your workflow or share the actions you
 
 Actions can run directly on a machine or in a Docker container. You can define an action's inputs, outputs, and environment variables.
 
-### Types of actions
+## Types of actions
 
 You can build Docker container and JavaScript actions. Actions require a metadata file to define the inputs, outputs and main entrypoint for your action. The metadata filename must be either `action.yml` or `action.yaml`. For more information, see "[Metadata syntax for {% data variables.product.prodname_actions %}](/articles/metadata-syntax-for-github-actions)."
 
@@ -41,27 +41,27 @@ You can build Docker container and JavaScript actions. Actions require a metadat
 | JavaScript | Linux, macOS, Windows |
 | Composite run steps | Linux, macOS, Windows |
 
-#### Docker container actions
+### Docker container actions
 
 Docker containers package the environment with the {% data variables.product.prodname_actions %} code. This creates a more consistent and reliable unit of work because the consumer of the action does not need to worry about the tools or dependencies.
 
 A Docker container allows you to use specific versions of an operating system, dependencies, tools, and code. For actions that must run in a specific environment configuration, Docker is an ideal option because you can customize the operating system and tools. Because of the latency to build and retrieve the container, Docker container actions are slower than JavaScript actions.
 
 Docker container actions can only execute on runners with a Linux operating system. {% data reusables.github-actions.self-hosted-runner-reqs-docker %}
 
-#### JavaScript actions
+### JavaScript actions
 
 JavaScript actions can run directly on a runner machine, and separate the action code from the environment used to run the code. Using a JavaScript action simplifies the action code and executes faster than a Docker container action.
 
 {% data reusables.github-actions.pure-javascript %}
 
 If you're developing a Node.js project, the {% data variables.product.prodname_actions %} Toolkit provides packages that you can use in your project to speed up development. For more information, see the [actions/toolkit](https://github.com/actions/toolkit) repository.
 
-#### Composite run steps actions
+### Composite run steps actions
 
 A _composite run steps_ action allows you to combine multiple workflow run steps within one action. For example, you can use this feature to bundle together multiple run commands into an action, and then have a workflow that executes the bundled commands a single step using that action. To see an example, check out "[Creating a composite run steps action](/actions/creating-actions/creating-a-composite-run-steps-action)".
 
-### Choosing a location for your action
+## Choosing a location for your action
 
 If you're developing an action for other people to use, we recommend keeping the action in its own repository instead of bundling it with other application code. This allows you to version, track, and release the action just like any other software.
 
@@ -71,7 +71,7 @@ Storing an action in its own repository makes it easier for the {% data variable
 
 {% if currentVersion == "free-pro-team@latest" %}If you're building an action that you don't plan to make available to the public, you {% else %} You{% endif %} can store the action's files in any location in your repository. If you plan to combine action, workflow, and application code in a single repository, we recommend storing actions in the `.github` directory. For example, `.github/actions/action-a` and `.github/actions/action-b`.
 
-### Compatibility with {% data variables.product.prodname_ghe_server %}
+## Compatibility with {% data variables.product.prodname_ghe_server %}
 
 To ensure that your action is compatible with {% data variables.product.prodname_ghe_server %}, you should make sure that you do not use any hard-coded references to {% data variables.product.prodname_dotcom %} API URLs. You should instead use environment variables to refer to the {% data variables.product.prodname_dotcom %} API:
 
@@ -80,19 +80,19 @@ To ensure that your action is compatible with {% data variables.product.prodname
 
 For more information, see "[Default environment variables](/actions/configuring-and-managing-workflows/using-environment-variables#default-environment-variables)."
 
-### Using release management for actions
+## Using release management for actions
 
 This section explains how you can use release management to distribute updates to your actions in a predictable way.
 
-#### Good practices for release management
+### Good practices for release management
 
 If you're developing an action for other people to use, we recommend using release management to control how you distribute updates. Users can expect an action's major version to include necessary critical fixes and security patches, while still remaining compatible with their existing workflows. You should consider releasing a new major version whenever your changes affect compatibility.
 
 Under this release management approach, users should not be referencing an action's default branch, as it's likely to contain the latest code and consequently might be unstable. Instead, you can recommend that your users specify a major version when using your action, and only direct them to a more specific version if they encounter issues.
 
 To use a specific action version, users can configure their {% data variables.product.prodname_actions %} workflow to target a tag, a commit's SHA, or a branch named for a release.
 
-#### Using tags for release management
+### Using tags for release management
 
 We recommend using tags for actions release management. Using this approach, your users can easily distinguish between major and minor versions:
 
@@ -116,7 +116,7 @@ steps:
     - uses: actions/[email protected]
 ```
 
-#### Using branches for release management
+### Using branches for release management
 
 If you prefer to use branch names for release management, this example demonstrates how to reference a named branch:
 
@@ -125,7 +125,7 @@ steps:
     - uses: actions/javascript-action@v1-beta
 ```
 
-#### Using a commit's SHA for release management
+### Using a commit's SHA for release management
 
 Each Git commit receives a calculated SHA value, which is unique and immutable. Your action's users might prefer to rely on a commit's SHA value, as this approach can be more reliable than specifying a tag, which could be deleted or moved. However, this means that users will not receive further updates made to the action. {% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "[email protected]" or currentVersion == "github-ae@latest" %}You must use a commit's full SHA value, and not an abbreviated value.{% else %}Using a commit's full SHA value instead of the abbreviated value can help prevent people from using a malicious commit that uses the same abbreviation.{% endif %}
 
@@ -134,7 +134,7 @@ steps:
     - uses: actions/javascript-action@172239021f7ba04fe7327647b213799853a9eb89
 ```
 
-### Creating a README file for your action
+## Creating a README file for your action
 
 We recommend creating a README file to help people learn how to use your action. You can include this information in your `README.md`:
 
@@ -145,11 +145,11 @@ We recommend creating a README file to help people learn how to use your action.
 - Environment variables the action uses
 - An example of how to use your action in a workflow
 
-### Comparing {% data variables.product.prodname_actions %} to {% data variables.product.prodname_github_apps %}
+## Comparing {% data variables.product.prodname_actions %} to {% data variables.product.prodname_github_apps %}
 
 {% data variables.product.prodname_marketplace %} offers tools to improve your workflow. Understanding the differences and the benefits of each tool will allow you to select the best tool for your job. For more information about building apps, see "[About apps](/apps/about-apps/)."
 
-#### Strengths of GitHub Actions and GitHub Apps
+### Strengths of GitHub Actions and GitHub Apps
 
 While both {% data variables.product.prodname_actions %} and {% data variables.product.prodname_github_app %}s provide ways to build automation and workflow tools, they each have strengths that make them useful in different ways.
 
@@ -166,6 +166,6 @@ While both {% data variables.product.prodname_actions %} and {% data variables.p
 * Don't require you to deploy code or serve an app.
 * Have a simple interface to create and use secrets, which enables actions to interact with third-party services without needing to store the credentials of the person using the action.
 
-### Further reading
+## Further reading
 
 - "[Development tools for {% data variables.product.prodname_actions %}](/articles/development-tools-for-github-actions)"

content/actions/creating-actions/creating-a-composite-run-steps-action.md

@@ -15,15 +15,15 @@ topics:
 {% data reusables.actions.enterprise-github-hosted-runners %}
 {% data reusables.actions.ae-beta %}
 
-### Introduction
+## Introduction
 
 In this guide, you'll learn about the basic components needed to create and use a packaged composite run steps action. To focus this guide on the components needed to package the action, the functionality of the action's code is minimal. The action prints "Hello World" and then "Goodbye",  or if you provide a custom name, it prints "Hello [who-to-greet]" and then "Goodbye". The action also maps a random number to the `random-number` output variable, and runs a script named `goodbye.sh`.
 
 Once you complete this project, you should understand how to build your own composite run steps action and test it in a workflow.
 
 {% data reusables.github-actions.context-injection-warning %}
 
-### Prerequisites
+## Prerequisites
 
 Before you begin, you'll create a {% data variables.product.product_name %} repository.
 
@@ -56,7 +56,7 @@ Before you begin, you'll create a {% data variables.product.product_name %} repo
   git push
   ```
 
-### Creating an action metadata file
+## Creating an action metadata file
 
 1. In the `hello-world-composite-run-steps-action` repository, create a new file called `action.yml` and add the following example code. For more information about this syntax, see "[`runs` for a composite run steps](/actions/creating-actions/metadata-syntax-for-github-actions#runs-for-composite-run-steps-actions)".
 
@@ -107,7 +107,7 @@ Before you begin, you'll create a {% data variables.product.product_name %} repo
   git push --follow-tags
   ```
 
-### Testing out your action in a workflow
+## Testing out your action in a workflow
 
 The following workflow code uses the completed hello world action that you made in "[Creating an action metadata file](/actions/creating-actions/creating-a-composite-run-steps-action#creating-an-action-metadata-file)".
 

content/actions/creating-actions/creating-a-docker-container-action.md

@@ -21,7 +21,7 @@ topics:
 {% data reusables.actions.enterprise-github-hosted-runners %}
 {% data reusables.actions.ae-beta %}
 
-### Introduction
+## Introduction
 
 In this guide, you'll learn about the basic components needed to create and use a packaged Docker container action. To focus this guide on the components needed to package the action, the functionality of the action's code is minimal. The action prints "Hello World" in the logs or "Hello [who-to-greet]" if you provide a custom name.
 
@@ -31,7 +31,7 @@ Once you complete this project, you should understand how to build your own Dock
 
 {% data reusables.github-actions.context-injection-warning %}
 
-### Prerequisites
+## Prerequisites
 
 You may find it helpful to have a basic understanding of {% data variables.product.prodname_actions %} environment variables and the Docker container filesystem:
 
@@ -54,7 +54,7 @@ Before you begin, you'll need to create a {% data variables.product.prodname_dot
   cd hello-world-docker-action
   ```
 
-### Creating a Dockerfile
+## Creating a Dockerfile
 
 In your new `hello-world-docker-action` directory, create a new `Dockerfile` file. For more information, see "[Dockerfile support for {% data variables.product.prodname_actions %}](/actions/creating-actions/dockerfile-support-for-github-actions)."
 
@@ -70,7 +70,7 @@ COPY entrypoint.sh /entrypoint.sh
 ENTRYPOINT ["/entrypoint.sh"]
 ```
 
-### Creating an action metadata file
+## Creating an action metadata file
 
 Create a new `action.yml` file in the `hello-world-docker-action` directory you created above. For more information, see "[Metadata syntax for {% data variables.product.prodname_actions %}](/actions/creating-actions/metadata-syntax-for-github-actions)."
 
@@ -100,7 +100,7 @@ This metadata defines one `who-to-greet`  input and one `time` output parameter.
 
 {% data variables.product.prodname_dotcom %} will build an image from your `Dockerfile`, and run commands in a new container using this image.
 
-### Writing the action code
+## Writing the action code
 
 You can choose any base Docker image and, therefore, any language for your action. The following shell script example uses the `who-to-greet` input variable to print "Hello [who-to-greet]" in the log file.
 
@@ -126,7 +126,7 @@ Next, the script gets the current time and sets it as an output variable that ac
   $ chmod +x entrypoint.sh
   ```
 
-### Creating a README
+## Creating a README
 
 To let people know how to use your action, you can create a README file. A README is most helpful when you plan to share your action publicly, but is also a great way to remind you or your team how to use the action.
 
@@ -147,13 +147,13 @@ This action prints "Hello World" or "Hello" + the name of a person to greet to t
 
 ## Inputs
 
-### `who-to-greet`
+## `who-to-greet`
 
 **Required** The name of the person to greet. Default `"World"`.
 
 ## Outputs
 
-### `time`
+## `time`
 
 The time we greeted you.
 
@@ -164,7 +164,7 @@ with:
   who-to-greet: 'Mona the Octocat'
 ```
 
-### Commit, tag, and push your action to {% data variables.product.product_name %}
+## Commit, tag, and push your action to {% data variables.product.product_name %}
 
 From your terminal, commit your `action.yml`, `entrypoint.sh`, `Dockerfile`, and `README.md` files.
 
@@ -177,13 +177,13 @@ git tag -a -m "My first action release" v1
 git push --follow-tags
 ```
 
-### Testing out your action in a workflow
+## Testing out your action in a workflow
 
 Now you're ready to test your action out in a workflow. When an action is in a private repository, the action can only be used in workflows in the same repository. Public actions can be used by workflows in any repository.
 
 {% data reusables.actions.enterprise-marketplace-actions %}
 
-#### Example using a public action
+### Example using a public action
 
 The following workflow code uses the completed _hello world_ action in the public [`actions/hello-world-docker-action`](https://github.com/actions/hello-world-docker-action) repository. Copy the following workflow example code into a `.github/workflows/main.yml` file, but replace the `actions/hello-world-docker-action` with your repository and action name. You can also replace the `who-to-greet` input with your name. {% if currentVersion == "free-pro-team@latest" %}Public actions can be used even if they're not published to {% data variables.product.prodname_marketplace %}. For more information, see "[Publishing an action](/actions/creating-actions/publishing-actions-in-github-marketplace#publishing-an-action)." {% endif %}
 
@@ -208,7 +208,7 @@ jobs:
 ```
 {% endraw %}
 
-#### Example using a private action
+### Example using a private action
 
 Copy the following example workflow code into a `.github/workflows/main.yml` file in your action's repository. You can also replace the `who-to-greet` input with your name. {% if currentVersion == "free-pro-team@latest" %}This private action can't be published to {% data variables.product.prodname_marketplace %}, and can only be used in this repository.{% endif %}