+ >
>
)
}
diff --git a/content/actions/learn-github-actions/understanding-github-actions.md b/content/actions/learn-github-actions/understanding-github-actions.md
index 9613ae2f2f..90de4101cd 100644
--- a/content/actions/learn-github-actions/understanding-github-actions.md
+++ b/content/actions/learn-github-actions/understanding-github-actions.md
@@ -23,48 +23,55 @@ topics:
## Overview
-{% data reusables.actions.about-actions %} {% data variables.product.prodname_actions %} are event-driven, meaning that you can run a series of commands after a specified event has occurred. For example, every time someone creates a pull request for a repository, you can automatically run a command that executes a software testing script.
+{% data reusables.actions.about-actions %} You can create workflows that build and test every pull request to your repository, or deploy merged pull requests to production.
-This diagram demonstrates how you can use {% data variables.product.prodname_actions %} to automatically run your software testing scripts. An event automatically triggers the _workflow_, which contains a _job_. The job then uses _steps_ to control the order in which _actions_ are run. These actions are the commands that automate your software testing.
+{% data variables.product.prodname_actions %} goes beyond just DevOps and lets you run workflows when other events happen in your repository. For example, you can run a workflow to automatically add the appropriate labels whenever someone creates a new issue in your repository.
-
+{% data variables.product.prodname_dotcom %} provides Linux, Windows, and macOS virtual machines to run your workflows, or you can host your own self-hosted runners in your own data center or cloud infrastructure.
## The components of {% data variables.product.prodname_actions %}
-Below is a list of the multiple {% data variables.product.prodname_actions %} components that work together to run jobs. You can see how these components interact with each other.
+You can configure a {% data variables.product.prodname_actions %} _workflow_ to be triggered when an _event_ occurs in your repository, such as a pull request being opened or an issue being created. Your workflow contains one or more _jobs_ which can run in sequential order or in parallel. Each job will run inside its own virtual machine _runner_, or inside a container, and has one or more _steps_ that either run a script that you define or run an _action_, which is a reusable extension that can simplify in your workflow.
-
+
### Workflows
-The workflow is an automated procedure that you add to your repository. Workflows are made up of one or more jobs and can be scheduled or triggered by an event. The workflow can be used to build, test, package, release, or deploy a project on {% data variables.product.prodname_dotcom %}. {% ifversion fpt or ghes > 3.3 or ghae-issue-4757 or ghec %}You can reference a workflow within another workflow, see "[Reusing workflows](/actions/learn-github-actions/reusing-workflows)."{% endif %}
+A workflow is a configurable automated process that will run one or more jobs. Workflows are defined by a YAML file checked in to your repository and will run when triggered by an event in your repository, or they can be triggered manually, or at a defined schedule.
+
+Your repository can have multiple workflows in a repository, each of which can perform a different set of steps. For example, you can have one workflow to build and test pull requests, another workflow to deploy your application every time a release is created, and still another workflow that adds a label every time someone opens a new issue.
+
+{% ifversion fpt or ghes > 3.3 or ghae-issue-4757 or ghec %}You can reference a workflow within another workflow, see "[Reusing workflows](/actions/learn-github-actions/reusing-workflows)."{% endif %}
### Events
-An event is a specific activity that triggers a workflow. For example, activity can originate from {% data variables.product.prodname_dotcom %} when someone pushes a commit to a repository or when an issue or pull request is created. You can also use the [repository dispatch webhook](/rest/reference/repos#create-a-repository-dispatch-event) to trigger a workflow when an external event occurs. For a complete list of events that can be used to trigger workflows, see [Events that trigger workflows](/actions/reference/events-that-trigger-workflows).
+An event is a specific activity in a repository that triggers a workflow run. For example, activity can originate from {% data variables.product.prodname_dotcom %} when someone creates a pull request, opens an issue, or pushes a commit to a repository. You can also trigger a workflow run on a schedule, by [posting to a REST API](/rest/reference/repos#create-a-repository-dispatch-event), or manually.
+
+For a complete list of events that can be used to trigger workflows, see [Events that trigger workflows](/actions/reference/events-that-trigger-workflows).
### Jobs
-A job is a set of steps that execute on the same runner. By default, a workflow with multiple jobs will run those jobs in parallel. You can also configure a workflow to run jobs sequentially. For example, a workflow can have two sequential jobs that build and test code, where the test job is dependent on the status of the build job. If the build job fails, the test job will not run.
+A job is a set of _steps_ in a workflow that execute on the same runner. Each step is either a shell script that will be executed, or an _action_ that will be run. Steps are executed in order and are dependent on each other. Since each step is executed on the same runner, you can share data from one step to another. For example, you can have a step that builds your application followed by a step that tests the application that was built.
-### Steps
-
-A step is an individual task that can run commands in a job. A step can be either an _action_ or a shell command. Each step in a job executes on the same runner, allowing the actions in that job to share data with each other.
+You can configure a job's dependencies with other jobs; by default, jobs have no dependencies and run in parallel with each other. When a job takes a dependency on another job, it will wait for the dependent job to complete before it can run. For example, you may have multiple build jobs for different architectures that have no dependencies, and a packaging job that is dependent on those jobs. The build jobs will run in parallel, and when they have all completed successfully, the packaging job will run.
### Actions
-_Actions_ are standalone commands that are combined into _steps_ to create a _job_. Actions are the smallest portable building block of a workflow. You can create your own actions, or use actions created by the {% data variables.product.prodname_dotcom %} community. To use an action in a workflow, you must include it as a step.
+An _action_ is a custom application for the {% data variables.product.prodname_actions %} platform that performs a complex but frequently repeated task. Use an action to help reduce the amount of repetitive code that you write in your workflow files. An action can pull your git repository from {% data variables.product.prodname_dotcom %}, set up the correct toolchain for your build environment, or set up the authentication to your cloud provider.
+
+You can write your own actions, or you can find actions to use in your workflows in the {% data variables.product.prodname_marketplace %}.
### Runners
-{% ifversion ghae %}A runner is a server that has the [{% data variables.product.prodname_actions %} runner application](https://github.com/actions/runner) installed. For {% data variables.product.prodname_ghe_managed %}, you can use the security hardened {% data variables.actions.hosted_runner %}s which are bundled with your instance in the cloud. A runner listens for available jobs, runs one job at a time, and reports the progress, logs, and results back to {% data variables.product.prodname_dotcom %}. {% data variables.actions.hosted_runner %}s run each workflow job in a fresh virtual environment. For more information, see "[About {% data variables.actions.hosted_runner %}s](/actions/using-github-hosted-runners/about-ae-hosted-runners)."
+{% ifversion ghae %}
+{% data reusables.actions.about-runners %} For {% data variables.product.prodname_ghe_managed %}, you can use the security hardened {% data variables.actions.hosted_runner %}s that are bundled with your instance in the cloud. If you need a different operating system or require a specific hardware configuration, you can host your own runners. For information on self-hosted runners, see "[Hosting your own runners](/actions/hosting-your-own-runners)."
{% else %}
-{% data reusables.actions.about-runners %} A runner listens for available jobs, runs one job at a time, and reports the progress, logs, and results back to {% data variables.product.prodname_dotcom %}. {% data variables.product.prodname_dotcom %}-hosted runners are based on Ubuntu Linux, Microsoft Windows, and macOS, and each job in a workflow runs in a fresh virtual environment. For information on {% data variables.product.prodname_dotcom %}-hosted runners, see "[About {% data variables.product.prodname_dotcom %}-hosted runners](/actions/using-github-hosted-runners/about-github-hosted-runners)." If you need a different operating system or require a specific hardware configuration, you can host your own runners. For information on self-hosted runners, see "[Hosting your own runners](/actions/hosting-your-own-runners)."
+{% data reusables.actions.about-runners %} Each runner can run a single job at a time. {% data variables.product.prodname_dotcom %} provides Ubuntu Linux, Microsoft Windows, and macOS runners to run your workflows; each workflow run executes in a fresh, newly-provisioned virtual machine. If you need a different operating system or require a specific hardware configuration, you can host your own runners. For information on self-hosted runners, see "[Hosting your own runners](/actions/hosting-your-own-runners)."
{% endif %}
## Create an example workflow
-{% data variables.product.prodname_actions %} uses YAML syntax to define the events, jobs, and steps. These YAML files are stored in your code repository, in a directory called `.github/workflows`.
+{% data variables.product.prodname_actions %} uses YAML syntax to define the workflow. Each workflow is stored as a separate YAML file in your code repository, in a directory called `.github/workflows`.
You can create an example workflow in your repository that automatically triggers a series of commands whenever code is pushed. In this workflow, {% data variables.product.prodname_actions %} checks out the pushed code, installs the software dependencies, and runs `bats -v`.
@@ -112,7 +119,7 @@ To help you understand how YAML syntax is used to create a workflow file, this s
```
- Specify the event that automatically triggers the workflow file. This example uses the push event, so that the jobs run every time someone pushes a change to the repository. You can set up the workflow to only run on certain branches, paths, or tags. For syntax examples including or excluding branches, paths, or tags, see "Workflow syntax for {% data variables.product.prodname_actions %}."
+Specifies the trigger for this workflow. This example uses the push event, so a workflow run is triggered every time someone pushes a change to the repository or merges a pull request. This is triggered by a push to every branch; for examples of syntax that runs only on pushes to specific branches, paths, or tags, see "Workflow syntax for {% data variables.product.prodname_actions %}."
@@ -123,7 +130,7 @@ To help you understand how YAML syntax is used to create a workflow file, this s
```
- Groups together all the jobs that run in the learn-github-actions workflow file.
+ Groups together all the jobs that run in the learn-github-actions workflow.
@@ -134,7 +141,7 @@ To help you understand how YAML syntax is used to create a workflow file, this s
```
- Defines the name of the check-bats-version job stored within the jobs section.
+Defines a job named check-bats-version. The child keys will define properties of the job.
@@ -145,7 +152,7 @@ To help you understand how YAML syntax is used to create a workflow file, this s
```
@@ -156,7 +163,7 @@ To help you understand how YAML syntax is used to create a workflow file, this s
```
- Groups together all the steps that run in the check-bats-version job. Each item nested under this section is a separate action or shell command.
+ Groups together all the steps that run in the check-bats-version job. Each item nested under this section is a separate action or shell script.
@@ -167,7 +174,7 @@ To help you understand how YAML syntax is used to create a workflow file, this s
```
- The uses keyword tells the job to retrieve v2 of the community action named actions/checkout@v2. This is an action that checks out your repository and downloads it to the runner, allowing you to run actions against your code (such as testing tools). You must use the checkout action any time your workflow will run against the repository's code or you are using an action defined in the repository.
+The uses keyword specifies that this step will run v2 of the actions/checkout action. This is an action that checks out your repository onto the runner, allowing you to run scripts or other actions against your code (such as build and test tools). You should use the checkout action any time your workflow will run against the repository's code.
@@ -180,7 +187,7 @@ To help you understand how YAML syntax is used to create a workflow file, this s
```
- This step uses the actions/setup-node@v2 action to install the specified version of the node software package on the runner, which gives you access to the npm command.
+ This step uses the actions/setup-node@v2 action to install the specified version of the Node.js (this example uses v14). This puts both the node and npm commands in your PATH.
@@ -209,13 +216,13 @@ To help you understand how YAML syntax is used to create a workflow file, this s
### Visualizing the workflow file
-In this diagram, you can see the workflow file you just created and how the {% data variables.product.prodname_actions %} components are organized in a hierarchy. Each step executes a single action or shell command. Steps 1 and 2 use prebuilt community actions. Steps 3 and 4 run shell commands directly on the runner. To find more prebuilt actions for your workflows, see "[Finding and customizing actions](/actions/learn-github-actions/finding-and-customizing-actions)."
+In this diagram, you can see the workflow file you just created and how the {% data variables.product.prodname_actions %} components are organized in a hierarchy. Each step executes a single action or shell script. Steps 1 and 2 run actions, while steps 3 and 4 run shell scripts. To find more prebuilt actions for your workflows, see "[Finding and customizing actions](/actions/learn-github-actions/finding-and-customizing-actions)."

-## Viewing the job's activity
+## Viewing the workflow's activity
-Once your job has started running, you can {% ifversion fpt or ghes > 3.0 or ghae or ghec %}see a visualization graph of the run's progress and {% endif %}view each step's activity on {% data variables.product.prodname_dotcom %}.
+Once your workflow has started running, you can {% ifversion fpt or ghes > 3.0 or ghae or ghec %}see a visualization graph of the run's progress and {% endif %}view each step's activity on {% data variables.product.prodname_dotcom %}.
{% data reusables.repositories.navigate-to-repo %}
1. Under your repository name, click **Actions**.
diff --git a/data/reusables/actions/about-actions.md b/data/reusables/actions/about-actions.md
index 04b25d13f2..995119f59d 100644
--- a/data/reusables/actions/about-actions.md
+++ b/data/reusables/actions/about-actions.md
@@ -1 +1 @@
-{% data variables.product.prodname_actions %} helps you automate tasks within your software development life cycle.
+{% data variables.product.prodname_actions %} is a continuous integration and continuous delivery (CI/CD) platform that allows you to automate your build, test, and deployment pipeline.
diff --git a/data/reusables/actions/about-runners.md b/data/reusables/actions/about-runners.md
index c39fcf6ebb..0b661b9ecf 100644
--- a/data/reusables/actions/about-runners.md
+++ b/data/reusables/actions/about-runners.md
@@ -1 +1 @@
-A runner is a server that has the [{% data variables.product.prodname_actions %} runner application](https://github.com/actions/runner) installed. You can use a runner hosted by {% data variables.product.prodname_dotcom %}, or you can host your own.
\ No newline at end of file
+A runner is a server that runs your workflows when they're triggered.
diff --git a/pages/[versionId]/index.tsx b/pages/[versionId]/index.tsx
index 209201d14a..7e27354506 100644
--- a/pages/[versionId]/index.tsx
+++ b/pages/[versionId]/index.tsx
@@ -1,4 +1,4 @@
-import LandingPage from '../index'
+import HomePage from '../index'
export { getServerSideProps } from '../index'
-export default LandingPage
+export default HomePage
diff --git a/pages/index.tsx b/pages/index.tsx
index 7ef3eaf0cf..e3b00cc927 100644
--- a/pages/index.tsx
+++ b/pages/index.tsx
@@ -1,24 +1,13 @@
import { GetServerSideProps } from 'next'
-import {
- MainContextT,
- MainContext,
- getMainContext,
- useMainContext,
- ProductT,
- ProductGroupT,
-} from 'components/context/MainContext'
+import { MainContextT, MainContext, getMainContext } from 'components/context/MainContext'
import React from 'react'
import { DefaultLayout } from 'components/DefaultLayout'
import { useTranslation } from 'components/hooks/useTranslation'
-import { useVersion } from 'components/hooks/useVersion'
-import { useRouter } from 'next/router'
-import { OctocatHeader } from 'components/landing/OctocatHeader'
import { ArticleList } from 'components/landing/ArticleList'
-import { Search } from 'components/Search'
-import { Link } from 'components/Link'
-import * as Octicons from '@primer/octicons-react'
+import { HomePageHero } from 'components/homepage/HomePageHero'
+import { ProductSelections } from 'components/homepage/ProductSelections'
type FeaturedLink = {
href: string
@@ -31,133 +20,29 @@ type Props = {
popularLinks: Array
gettingStartedLinks: Array
}
-export default function MainLanding({ mainContext, gettingStartedLinks, popularLinks }: Props) {
+
+export default function MainHomePage({ mainContext, gettingStartedLinks, popularLinks }: Props) {
return (
-
+
)
}
-type LandingPageProps = {
+type HomePageProps = {
popularLinks: Array
gettingStartedLinks: Array
}
-function LandingPage(props: LandingPageProps) {
- const router = useRouter()
+function HomePage(props: HomePageProps) {
const { gettingStartedLinks, popularLinks } = props
- const { productGroups, isFPT } = useMainContext()
- const { currentVersion } = useVersion()
- const { t } = useTranslation(['homepage', 'search', 'toc'])
-
- function showProduct(product: ProductT) {
- return isFPT || product.versions?.includes(currentVersion) || product.external
- }
-
- function href(product: ProductT) {
- return `${!product.external ? `/${router.locale}` : ''}${
- product.versions?.includes(currentVersion) && !isFPT
- ? `/${currentVersion}/${product.id}`
- : product.href
- }`
- }
-
- const groupIcon = {
- height: '22px',
- }
-
- function icon(group: ProductGroupT) {
- if (group.icon) {
- return (
-
diff --git a/tests/routing/release-notes.js b/tests/routing/release-notes.js
index df16f9332d..eae8f2d939 100644
--- a/tests/routing/release-notes.js
+++ b/tests/routing/release-notes.js
@@ -1,5 +1,7 @@
-import { get, getDOM } from '../helpers/supertest.js'
import { jest } from '@jest/globals'
+import nock from 'nock'
+
+import { get, getDOM } from '../helpers/supertest.js'
jest.useFakeTimers('legacy')
@@ -11,6 +13,17 @@ describe('release notes', () => {
// advance to call out that problem specifically rather than misleadingly
// attributing it to the first test
await get('/')
+
+ nock('https://github.github.com')
+ .get(
+ '/help-docs-archived-enterprise-versions/2.19/en/enterprise-server@2.19/admin/release-notes'
+ )
+ .reply(404)
+ nock('https://github.github.com')
+ .get('/help-docs-archived-enterprise-versions/2.19/redirects.json')
+ .reply(200, {
+ emp: 'ty',
+ })
})
it('redirects to the release notes on enterprise.github.com if none are present for this version here', async () => {