docs-bot
@@ -31,7 +31,7 @@ If you believe that {% data variables.product.prodname_secret_scanning %} should
|
||||
|
||||
## Supported secrets
|
||||
|
||||
This table lists the secrets supported by {% data variables.product.prodname_secret_scanning %}. You can see the types of alert that get generated for each token, as well as whether a validity check is performed on the token.
|
||||
The tables list the secrets supported by {% data variables.product.prodname_secret_scanning %} for each secret type. Information in the tables may include this data:
|
||||
|
||||
* **Provider:** Name of the token provider.{% ifversion fpt or ghec %}
|
||||
* **Partner:** Token for which leaks are reported to the relevant token partner. Applies to public repositories and all gists, including secret gists. Secret gists are not private and can be accessed by anyone with the URL. See [About gists](/get-started/writing-on-github/editing-and-sharing-content-with-gists/creating-gists#about-gists).
|
||||
@@ -44,8 +44,8 @@ This table lists the secrets supported by {% data variables.product.prodname_sec
|
||||
* Applies to private repositories where {% data variables.product.prodname_GH_secret_protection %} and {% data variables.product.prodname_secret_scanning %} are enabled.
|
||||
* Includes {% ifversion secret-scanning-alert-experimental-list %}default{% else %}high confidence{% endif %} tokens, which relate to supported patterns and specified custom patterns, as well as non-provider tokens such as private keys, which often result in false positives.{% endif %}
|
||||
* **Push protection:** Token for which leaks are reported to users on {% data variables.product.prodname_dotcom %}. Applies to repositories with {% data variables.product.prodname_secret_scanning %} and push protection enabled.
|
||||
|
||||
* **Validity check:** Token for which a validity check is implemented. {% ifversion secret-scanning-validity-check-partner-patterns %}For partner tokens, {% data variables.product.prodname_dotcom %} sends the token to the relevant partner. Note that not all partners are based in the United States. For more information, see [{% data variables.product.prodname_AS %}](/free-pro-team@latest/site-policy/github-terms/github-terms-for-additional-products-and-features#advanced-security) in the Site Policy documentation.{% else %} Currently only applies to {% data variables.product.prodname_dotcom %} tokens.{% endif %}
|
||||
* **Base64:** Token for which Base64-encoded versions are supported.
|
||||
|
||||
### Non-provider patterns
|
||||
|
||||
|
||||
@@ -6,3 +6,4 @@
|
||||
|
||||
> [!WARNING]
|
||||
> `ghe-repl-start` causes a brief outage on the primary server, during which users may see internal server errors. To provide a friendlier message, run `ghe-maintenance -s` on the primary node before running `ghe-repl-start` on the replica node to put the appliance in maintenance mode. Once replication starts, disable maintenance mode with `ghe-maintenance -u`. Git replication will not progress while the primary node is in maintenance mode.
|
||||
> If you are running version 3.14.20, 3.15.15, 3.16.11, 3.17.8, 3.18.2, or a later version including future releases like 3.19, you no longer need to put the primary in maintenance mode prior to running `ghe-repl-start`. This command is no longer expected to cause an outage on the primary server. However, when setting up a new replica, `ghe-repl-start` won't cause an outage as long as you run `ghe-config-apply` between `ghe-repl-setup` and `ghe-repl-start`. Skipping `ghe-config-apply` and going straight from `ghe-repl-setup` to `ghe-repl-start` will still result in an outage.
|
||||
|
||||
87
src/journeys/README.md
Normal file
87
src/journeys/README.md
Normal file
@@ -0,0 +1,87 @@
|
||||
# Journeys
|
||||
|
||||
The **journeys** subject provides guided learning experiences (called "tracks") that help users navigate through a sequence of related documentation articles. Tracks appear on special landing pages and provide contextual navigation to move through articles in a structured learning path.
|
||||
|
||||
## Purpose & Scope
|
||||
|
||||
This subject is responsible for:
|
||||
- Rendering journey landing pages that display multiple learning tracks
|
||||
- Providing prev/next navigation within journey track articles
|
||||
- Resolving journey context based on the current article path
|
||||
- Rendering Liquid templates in journey metadata (titles, descriptions, guide paths)
|
||||
|
||||
Journey tracks are defined in article frontmatter using the `journeyTracks` field on pages with `layout: journey-landing`.
|
||||
|
||||
## Architecture & Key Assets
|
||||
|
||||
```
|
||||
src/journeys/
|
||||
├── components/
|
||||
│ ├── JourneyTrackCard.tsx # Card showing journey progress with next/prev links
|
||||
│ ├── JourneyTrackNav.tsx # Navigation bar for prev/next articles in a track
|
||||
│ └── index.ts # Component exports
|
||||
├── lib/
|
||||
│ ├── get-link-data.ts # Fetches title and href data for journey guide links
|
||||
│ └── journey-path-resolver.ts # Core logic: resolves journey context and tracks
|
||||
├── middleware/
|
||||
│ └── journey-track.ts # Express middleware that attaches journey data to requests
|
||||
└── tests/
|
||||
└── journey-path-resolver.ts # Unit tests for journey resolution logic
|
||||
```
|
||||
|
||||
|
||||
|
||||
## Setup & Usage
|
||||
|
||||
### Prerequisites
|
||||
- Journey landing pages must have `layout: journey-landing` in their frontmatter
|
||||
- Journey tracks are defined in the `journeyTracks` frontmatter field (see example below)
|
||||
|
||||
### Running tests
|
||||
```bash
|
||||
npm run test -- src/journeys/tests
|
||||
```
|
||||
|
||||
### Example frontmatter for journey landing page
|
||||
```yaml
|
||||
---
|
||||
title: Enterprise onboarding
|
||||
layout: journey-landing
|
||||
journeyTracks:
|
||||
- id: 'getting_started'
|
||||
title: 'Getting started with {% data variables.product.prodname_ghe_cloud %}'
|
||||
description: 'Master the fundamentals and get started with a trial.'
|
||||
guides:
|
||||
- '/enterprise-onboarding/choose-an-enterprise-type'
|
||||
- '/enterprise-onboarding/setting-up-a-trial'
|
||||
- '/enterprise-onboarding/adding-users'
|
||||
---
|
||||
```
|
||||
|
||||
## Data & External Dependencies
|
||||
|
||||
### Data inputs
|
||||
- **Content frontmatter**: `journeyTracks` field on landing pages defines track structure
|
||||
- **Article metadata**: Article titles and paths are resolved via `get-link-data.ts`
|
||||
- **Liquid variables**: Track titles, descriptions, and guide paths support Liquid templating
|
||||
|
||||
### Dependencies
|
||||
- **`@/content-render`**: Used to render Liquid templates in journey metadata
|
||||
- **`@/frame/lib/path-utils`**: Normalizes paths for consistent matching
|
||||
- **`@/versions`**: Checks version compatibility between journey pages and articles
|
||||
- **`@/languages`**: Executes rendering with fallback for internationalization
|
||||
- **`@/landings`**: Journey components are consumed by landing page layouts
|
||||
|
||||
### Data outputs
|
||||
- **`req.context.currentJourneyTrack`**: Journey context object with track info and prev/next links
|
||||
- **`req.context.page.resolvedJourneyTracks`**: Array of resolved track data for landing pages
|
||||
|
||||
## Current State & Next Steps
|
||||
|
||||
### Known limitations
|
||||
- Journey tracks currently inherit version constraints from their landing page
|
||||
- Path normalization logic must stay synchronized with other path-handling middleware
|
||||
- Journey context resolution has some performance overhead due to iterating all pages
|
||||
- Currently only support a particular page belonging to a single journey track/step - we won't show nav components for all the journeys an article belongs to
|
||||
|
||||
Continued work to expand and add more journey tracks.
|
||||
@@ -1,7 +1,65 @@
|
||||
# Landing pages
|
||||
|
||||
Landing pages include the Docs home page, the product landing pages, and product guides pages.
|
||||
The landings subject provides components and logic for rendering various types of landing pages across docs.github.com, including the Docs home page, product landing pages, product guides pages, category pages, and specialized layouts like journey and discovery landings.
|
||||
|
||||
## What landing pages are for
|
||||
## Purpose & Scope
|
||||
|
||||
Landing pages provide a hierarchical view of their area, making navigating the Docs easier.
|
||||
This subject is responsible for:
|
||||
- Rendering different landing page layouts (product, guides, category, journey, discovery, bespoke)
|
||||
- Building and displaying featured links, article cards, and guide cards
|
||||
- Managing landing page context and data requirements
|
||||
- Providing hierarchical navigation for products and categories
|
||||
- Displaying article carousels and product releases
|
||||
|
||||
Landing pages serve as navigational hubs that provide a hierarchical view of their area, making it easier to find and discover documentation.
|
||||
|
||||
## Architecture & Key Assets
|
||||
|
||||
| Landing Page Type | Layout Value | Purpose |
|
||||
|-------------------|--------------|---------|
|
||||
| Product landing | `product-landing` | Product overview pages with featured links and release notes |
|
||||
| Product guides | `product-guides` | Product guides listing organized by categories |
|
||||
| Category landing | `category-landing` | Category pages with hierarchical navigation |
|
||||
| Table of contents | `toc-landing` | Table of contents pages |
|
||||
| Journey landing | `journey-landing` | Guided learning journey pages with track navigation |
|
||||
| Discovery landing | `discovery-landing` | Discovery/exploration pages |
|
||||
| Home page | (special) | Docs.github.com homepage |
|
||||
|
||||
## Setup & Usage
|
||||
|
||||
### Running tests
|
||||
|
||||
```bash
|
||||
npm run test -- src/landings/tests
|
||||
```
|
||||
|
||||
## Data & External Dependencies
|
||||
|
||||
### Data inputs
|
||||
- Page frontmatter: `layout`, `featuredLinks`, `journeyTracks`, etc.
|
||||
- Content tree: Used to build TOC and navigation hierarchies
|
||||
- Product metadata: Product names, versions, release information
|
||||
|
||||
### Dependencies
|
||||
- [`@/frame`](../frame/README.md) - Context object, page data, shared components
|
||||
- [`@/content-render`](../content-render/README.md) - Renders Liquid in featured link titles
|
||||
- [`@/learning-track`](../learning-track/README.md) - Learning track data resolution
|
||||
- [`@/journeys`](../journeys/README.md) - Journey track components and data
|
||||
- [`@/products`](../products/README.md) - Product metadata and groupings
|
||||
- [`@/versions`](../versions/README.md) - Version-aware content filtering
|
||||
|
||||
### Data outputs
|
||||
- `req.context.featuredLinks` - Resolved featured link data
|
||||
- Landing page contexts - Various context objects passed to React components
|
||||
- Rendered landing pages - Final HTML output
|
||||
|
||||
## Current State & Next Steps
|
||||
|
||||
### Known limitations
|
||||
- Multiple similar but distinct landing components (could be consolidated)
|
||||
- Featured links limited to 4 per category to avoid overly tall columns
|
||||
- Bespoke landing pages require custom components rather than data-driven approach
|
||||
|
||||
### Areas for improvement
|
||||
- Standardize landing page patterns and consolidate overlapping types
|
||||
- Make landing pages more data-driven and less code-heavy
|
||||
Reference in New Issue
Block a user