Merge pull request #385 from pyOpenSci/doc/github-actions

docs: fix typos GitHub action -> GitHub Actions

TRANSLATING.md

@@ -265,7 +265,7 @@ When you submit a PR for a translation, you should only include changes to one l
 
 Translations PRs will be tagged with a label indicating the language to make them easier to identify and review. For example, contributions to the Spanish translation will be tagged with 'lang-es'.
 
-TODO: This tagging could be automated with a GitHub action.
+TODO: This tagging could be automated with a GitHub Actions.
 
 When you submit the PR, make sure to include a short description of the changes you made and any context that might be helpful for the reviewer (e.g., you translated new strings, you reviewed fuzzy entries, you fixed typos, etc.)
 

package-structure-code/python-package-versions.md

@@ -105,7 +105,7 @@ package versions:
 ### Semantic release, vs version control based vs manual version bumping
 
 Generally semantic release and version control system tools
-can be setup to run automatically on GitHub using GitHub actions.
+can be setup to run automatically on GitHub using GitHub Actions.
 This means that you can create a workflow where a GitHub release
 and associated new version tag is used to trigger an automated
 build that:

tests/index.md

@@ -53,7 +53,7 @@ of Python, then using an automation tool such as nox to run your tests is useful
 :link-type: doc
 :class-card: left-aligned
 
-Continuous integration platforms such as GitHub actions can be
+Continuous integration platforms such as GitHub Actions can be
 useful for running your tests across both different Python versions
 and different operating systems. Learn about setting up tests to run in Continuous Integration here.
 :::

tests/tests-ci.md

@@ -19,9 +19,9 @@ It allows users to contribute code, documentation fixes and more without
 having to create development environments, run tests and build documentation
 locally.
 
-## Example GitHub action that runs tests
+## Example GitHub Actions that runs tests
 
-Below is an example GitHub action that runs tests using nox
+Below is an example GitHub Actions that runs tests using nox
 across both Windows, Mac and Linux and on Python versions
 3.9-3.11.
 

tests/write-tests.md

@@ -18,7 +18,7 @@ Writing tests for your Python package is important because:
 - **Fearless Refactoring:** Refactoring means making improvements to your code structure without changing its behavior. Tests empower you to make these changes as if you break something, test failures will let you know.
 - **Documentation:** Tests serve as technical examples of how to use your package. This can be helpful for a new technical contributor that wants to contribute code to your package. They can look at your tests to understand how parts of your code functionality fits together.
 - **Long-Term ease of maintenance:** As your package evolves, tests ensure that your code continues to behave as expected, even as you make changes over time. Thus you are helping your future self when writing tests.
-- **Easier pull request reviews:** By running your tests in a CI framework such as GitHub actions, each time you or a contributor makes a change to your code-base, you can catch issues and things that may have changed in your code base. This ensures that your software behaves the way you expect it to.
+- **Easier pull request reviews:** By running your tests in a CI framework such as GitHub Actions, each time you or a contributor makes a change to your code-base, you can catch issues and things that may have changed in your code base. This ensures that your software behaves the way you expect it to.
 
 ### Tests for user edge cases
 

tutorials/publish-pypi.md

@@ -58,7 +58,7 @@ to TestPyPI. You need to:
 1. **Publish to TestPyPI using `hatch publish`**
 
 In a future lesson, you will learn how to create an automated
-GitHub action workflow that publishes an updated
+GitHub Actions workflow that publishes an updated
 version of your package to PyPI every time you create a GitHub release.
 
 :::{admonition} Learn more about building Python packages in our guide
@@ -360,7 +360,7 @@ For long run maintenance of your package, you have two options
 related to PyPI publication.
 
 1. You can create a package-specific token which you will use to publish your package (manually) to PyPI. This is a great option if you don't wish to automate your PyPI publication workflow.
-2. You can also create an automated publication workflow on GitHub using GitHub actions. This is a great way to make the publication process easier and it also supports a growing maintainer team. In this case we suggest you don't worry about the token and instead setup a specific GitHub action that publishes your package when you make a release. You can then create a "trusted publisher" workflow on PyPI.
+2. You can also create an automated publication workflow on GitHub using GitHub Actions. This is a great way to make the publication process easier and it also supports a growing maintainer team. In this case we suggest you don't worry about the token and instead setup a specific GitHub Actions that publishes your package when you make a release. You can then create a "trusted publisher" workflow on PyPI.
 
 You will learn how to create the automated trusted publisher workflow in a followup lesson.