Refactored documentation to make it AI and human friendly.#2248
Merged
AlexSkrypnyk merged 1 commit intomainfrom Feb 8, 2026
Merged
Refactored documentation to make it AI and human friendly.#2248AlexSkrypnyk merged 1 commit intomainfrom
AlexSkrypnyk merged 1 commit intomainfrom
Conversation
WalkthroughLarge-scale documentation restructure converting the "workflows" model into distinct "development", "deployment", and "releasing" sections; standardized terminology to "automations/scripts"; added many new MDX docs (development, deployment, releasing pages), redirects, updated doc links in env/scripts, added CLAUDE guides, and small installer/test tooling updates. Changes
Sequence Diagram(s)(omitted — changes are documentation and redirects, no new multi-component runtime flow introduced) Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Possibly related PRs
Suggested labels
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In `@CLAUDE.md`:
- Around line 803-819: Add a preparatory step to ensure the .data directory
exists before the curl cookie save in Step 3: check for or create the .data
directory (mkdir -p .data) immediately before the curl -k -c .data/cookies.txt
-L "LOGIN_URL" command so that saving to .data/cookies.txt cannot fail if the
directory is missing; update the Step 3 text to include this directory creation
instruction and mention .data/cookies.txt explicitly.
- Around line 833-841: Add a short cleanup recommendation to the "Important
Notes" section: instruct users to delete the .data/cookies.txt file after use to
reduce the risk of stale authenticated sessions, and mention when (e.g., after
completing one-time login or when session is no longer needed) and how (simple
rm or manual delete) to perform the cleanup; reference the existing items
"Cookie storage" and "One-time use" so readers see the relation to .data/ and
`ahoy login`.
CLAUDE.md
Outdated
Comment on lines
803
to
819
| ```bash | ||
| # Step 1: Get the site URL from project info | ||
| ahoy info | ||
| # Note the URL (e.g., http://your-project.docker.amazee.io) | ||
|
|
||
| # Step 2: Get a one-time login URL | ||
| ahoy login | ||
| # Output example: http://your-project.docker.amazee.io/user/reset/1/1234567890/abc123/login | ||
|
|
||
| # Step 3: Authenticate and save session cookies | ||
| # Replace LOGIN_URL with the full URL from Step 2 | ||
| curl -k -c .data/cookies.txt -L "LOGIN_URL" | ||
|
|
||
| # Step 4: Access any authenticated page using saved cookies | ||
| # Replace SITE_URL with your site URL from Step 1 | ||
| curl -k -b .data/cookies.txt "SITE_URL/admin/content" | ||
|
|
There was a problem hiding this comment.
Ensure .data/ exists before saving cookies.
If the directory doesn’t exist, curl -c .data/cookies.txt will fail. Add an explicit mkdir -p .data step before Step 3.
🔧 Suggested doc tweak
# Step 2: Get a one-time login URL
ahoy login
# Output example: http://your-project.docker.amazee.io/user/reset/1/1234567890/abc123/login
# Step 3: Authenticate and save session cookies
+# Ensure cookie directory exists
+mkdir -p .data
# Replace LOGIN_URL with the full URL from Step 2
curl -k -c .data/cookies.txt -L "LOGIN_URL"🤖 Prompt for AI Agents
In `@CLAUDE.md` around lines 803 - 819, Add a preparatory step to ensure the .data
directory exists before the curl cookie save in Step 3: check for or create the
.data directory (mkdir -p .data) immediately before the curl -k -c
.data/cookies.txt -L "LOGIN_URL" command so that saving to .data/cookies.txt
cannot fail if the directory is missing; update the Step 3 text to include this
directory creation instruction and mention .data/cookies.txt explicitly.
CLAUDE.md
Outdated
Comment on lines
833
to
841
| #### Important Notes | ||
|
|
||
| - **Cookie storage**: Always use `.data/` directory - it is gitignored and won't | ||
| be committed | ||
| - **Session expiry**: Cookies expire after session timeout; regenerate with | ||
| Steps 2-3 as needed | ||
| - **Login URL format**: `http://SITE/user/reset/UID/TIMESTAMP/HASH/login` | ||
| - **One-time use**: Login URLs from `ahoy login` can only be used once; run | ||
| `ahoy login` again if needed |
There was a problem hiding this comment.
Add cleanup guidance for stored session cookies.
Given these cookies grant authenticated access, recommend deleting .data/cookies.txt after use to reduce risk of stale sessions.
🔧 Suggested doc tweak
- **One-time use**: Login URLs from `ahoy login` can only be used once; run
`ahoy login` again if needed
+- **Cleanup**: Remove `.data/cookies.txt` after troubleshooting to avoid leaving
+ authenticated sessions on disk🤖 Prompt for AI Agents
In `@CLAUDE.md` around lines 833 - 841, Add a short cleanup recommendation to the
"Important Notes" section: instruct users to delete the .data/cookies.txt file
after use to reduce the risk of stale authenticated sessions, and mention when
(e.g., after completing one-time login or when session is no longer needed) and
how (simple rm or manual delete) to perform the cleanup; reference the existing
items "Cookie storage" and "One-time use" so readers see the relation to .data/
and `ahoy login`.
This comment has been minimized.
This comment has been minimized.
Member
Author
|
Member
Author
|
Member
Author
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #2248 +/- ##
==========================================
- Coverage 76.85% 76.32% -0.53%
==========================================
Files 112 105 -7
Lines 5846 5711 -135
Branches 44 0 -44
==========================================
- Hits 4493 4359 -134
+ Misses 1353 1352 -1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
AlexSkrypnyk
changed the title
This comment has been minimized.
This comment has been minimized.
Member
Author
|
There was a problem hiding this comment.
Actionable comments posted: 13
🤖 Fix all issues with AI agents
In @.vortex/docs/content/workflows/development/composer.mdx:
- Around line 207-211: The documentation incorrectly states "Composer 2.9.0
introduced automatic security auditing"; update that phrase to "Composer 2.4.0
introduced automatic security auditing" in the Security auditing section
(replace the text string "Composer 2.9.0 introduced automatic security auditing"
with "Composer 2.4.0 introduced automatic security auditing") so the document
correctly cites the version that added the feature.
In @.vortex/docs/content/workflows/development/README.mdx:
- Line 144: Replace the legacy Docker v1 CLI usage in the example command
"docker-compose logs --tail=50 web" with the Docker v2 syntax "docker compose
logs --tail=50 web"; update that exact command string (and any other occurrences
of "docker-compose" in the same README) so examples consistently use "docker
compose".
- Line 119: The documentation uses the old docker-compose v1 syntax string
"docker-compose ps" on the line shown; update that command to the modern v2
syntax "docker compose ps" to match other docs and maintain consistency across
the PR, ensuring any occurrences of the hyphenated form (e.g., "docker-compose")
in this README.mdx are replaced with the space-separated "docker compose".
- Around line 155-157: The import statement for the CodeLifecycle component is
placed inside a <details> block; move the import line "import CodeLifecycle from
'../_code-lifecycle.mdx';" to the module top-level immediately after the
frontmatter (near the top of the file) so imports are valid for Docusaurus, and
leave only the JSX tag "<CodeLifecycle />" inside the existing details block to
render the component.
In @.vortex/docs/content/workflows/notifications/github.mdx:
- Line 25: The doc shows a mismatch in case for the environment type: the
variable VORTEX_NOTIFY_GITHUB_ENVIRONMENT_TYPE lists default `PR` but the
allowed value `pr` is lowercase; update the documentation to be consistent by
either normalizing the displayed values (e.g., use lowercase `pr` in the default
and options) or explicitly state the case sensitivity (e.g., "values are
case-insensitive; accepted values: production/staging/uat/dev/pr (default:
PR)"). Ensure the variable name VORTEX_NOTIFY_GITHUB_ENVIRONMENT_TYPE and the
set of allowed values are consistent and unambiguous.
In @.vortex/docs/content/workflows/notifications/README.mdx:
- Around line 24-26: Update the channel list display to use the official
capitalization "GitHub": replace the backticked display text `github` with
`GitHub` in the "Available channels" list (the entry currently written as
[`github`](github)), and also search the document for any other occurrences of
the backticked `github` display text and change them to `GitHub` to keep
capitalization consistent.
In @.vortex/docs/content/workflows/notifications/slack.mdx:
- Line 8: Replace the incorrect sentence "Post deployment notification to Slack
a channel." with the corrected phrase "Post deployment notification to a Slack
channel." in the Slack notification doc (look for the exact string "Post
deployment notification to Slack a channel." in slack.mdx) so the word order and
article usage are fixed.
In @.vortex/docs/content/workflows/releasing/README.mdx:
- Around line 37-38: The Development bullet contains a sentence fragment ("not
yet released. May be unstable, but CI tests should pass."); update the
"**Development**" line so it is a single complete sentence (e.g., "Latest
development code, not yet released and may be unstable, but CI tests should
pass.") ensuring the "**Development**" label and the "**Stage**" bullet remain
unchanged.
- Line 113: The link target "notifications/newrelic" in the README (the arrowed
link line) is incorrect for the current document location; update the Markdown
link target from "notifications/newrelic" to "../notifications/newrelic" so it
points to the correct New Relic notification page.
In @.vortex/docs/content/workflows/testing/behat.mdx:
- Around line 165-170: Replace the incorrect article in the Gherkin example:
find the line "As a authenticated user" in the Behat example block and change it
to "As an authenticated user" (update the text inside the fenced gherkin snippet
so the four lines read As a site visitor, As a site administrator, As a content
editor, As an authenticated user).
- Around line 46-53: The example showing tagged scenarios uses an unnecessary
end-of-options separator; locate the line containing "docker compose exec cli
vendor/bin/behat -- --tags=@smoke" and remove the extra "--" so the Behat option
is passed directly to vendor/bin/behat (i.e., invoke vendor/bin/behat with the
--tags option rather than placing it after an end-of-options marker).
In `@CLAUDE.md`:
- Around line 34-38: The Drush task list is missing the database update command;
add "ahoy drush updatedb" into the list and place it before the existing "ahoy
drush cim" entry so the recommended deployment order runs database updates prior
to importing configuration (update the block that currently contains "ahoy drush
cr", "ahoy drush cex", "ahoy drush cim", "ahoy drush uli" to include "ahoy drush
updatedb" immediately before "ahoy drush cim").
- Around line 49-55: The documented PHPUnit command in CLAUDE.md uses the wrong
flag; replace the incorrect token "--filters=TestClassName" with the correct
PHPUnit flag "--filter=TestClassName" so the example command "ahoy test --
--filters=TestClassName" becomes "ahoy test -- --filter=TestClassName"; update
the single occurrence of "--filters=TestClassName" to "--filter=TestClassName"
(search for the string "--filters" or the example "ahoy test --
--filters=TestClassName" to locate the line).
| ### Database connection errors | ||
|
|
||
| ```bash | ||
| docker-compose ps # Check if database container is running |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Inconsistent Docker Compose command syntax.
Line 119 uses docker-compose (v1 syntax), while other documentation files in this PR use docker compose (v2 syntax without hyphen). Consider using the modern docker compose syntax consistently throughout the documentation.
Suggested fix
-docker-compose ps # Check if database container is running
+docker compose ps # Check if database container is running📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| docker-compose ps # Check if database container is running | |
| docker compose ps # Check if database container is running |
🤖 Prompt for AI Agents
In @.vortex/docs/content/workflows/development/README.mdx at line 119, The
documentation uses the old docker-compose v1 syntax string "docker-compose ps"
on the line shown; update that command to the modern v2 syntax "docker compose
ps" to match other docs and maintain consistency across the PR, ensuring any
occurrences of the hyphenated form (e.g., "docker-compose") in this README.mdx
are replaced with the space-separated "docker compose".
| ahoy logs | ||
|
|
||
| # Check container logs | ||
| docker-compose logs --tail=50 web |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Same inconsistency: use docker compose (v2 syntax).
Suggested fix
-docker-compose logs --tail=50 web
+docker compose logs --tail=50 web📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| docker-compose logs --tail=50 web | |
| docker compose logs --tail=50 web |
🤖 Prompt for AI Agents
In @.vortex/docs/content/workflows/development/README.mdx at line 144, Replace
the legacy Docker v1 CLI usage in the example command "docker-compose logs
--tail=50 web" with the Docker v2 syntax "docker compose logs --tail=50 web";
update that exact command string (and any other occurrences of "docker-compose"
in the same README) so examples consistently use "docker compose".
Comment on lines
+155
to
+157
| import CodeLifecycle from '../_code-lifecycle.mdx'; | ||
|
|
||
| <CodeLifecycle /> |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n ".vortex/docs/content/workflows/development/README.mdx" | sed -n '140,170p'Repository: drevops/vortex
Length of output: 871
🌐 Web query:
Docusaurus MDX import inside details collapsible block rendering
💡 Result:
In Docusaurus MDX, don’t put import … statements inside a <details> block (or anywhere other than the MDX module “top level”). Instead, import at the top of the .mdx file and render the imported component inside the <details> content. Docusaurus explicitly supports importing one MDX file as a React component and embedding it elsewhere. [1]
import Extra from './_extra.mdx';
<details>
<summary>More</summary>
<Extra />
</details>If your <details> “collapsible” renders oddly, keep <summary> on a single line and add a blank line after it, because MDX can inject extra <p> wrappers that break the expected <details>/<summary> layout. [2]
Sources:
[1] Docusaurus docs — “MDX and React” (Importing Markdown) https://docusaurus.io/docs/markdown-features/react
[2] Docusaurus docs — “Markdown Features” (Details + note about <summary> and MDX <p> wrappers) https://docusaurus.io/docs/3.7.0/markdown-features
🏁 Script executed:
cat -n ".vortex/docs/content/workflows/development/README.mdx" | head -20Repository: drevops/vortex
Length of output: 754
Move the CodeLifecycle import to the top of the file (after the frontmatter).
The import statement on line 155 is inside the <details> block, which violates Docusaurus MDX requirements. Imports must be at the module top-level. Move import CodeLifecycle from '../_code-lifecycle.mdx'; to line 5 (after the frontmatter) and keep only <CodeLifecycle /> inside the details block. Without this change, Docusaurus will fail to process the import and the component won't render.
🤖 Prompt for AI Agents
In @.vortex/docs/content/workflows/development/README.mdx around lines 155 -
157, The import statement for the CodeLifecycle component is placed inside a
<details> block; move the import line "import CodeLifecycle from
'../_code-lifecycle.mdx';" to the module top-level immediately after the
frontmatter (near the top of the file) so imports are valid for Docusaurus, and
leave only the JSX tag "<CodeLifecycle />" inside the existing details block to
render the component.
| |----------------------------------------|----------|---------------------------------|----------|-----------------------------------------------------------| | ||
| | `VORTEX_NOTIFY_GITHUB_TOKEN` | **Yes** | | Hosting | GitHub notification personal access token | | ||
| | `VORTEX_NOTIFY_GITHUB_REPOSITORY` | **Yes** | | Hosting | GitHub notification repository in `owner/repo` format | | ||
| | `VORTEX_NOTIFY_GITHUB_ENVIRONMENT_TYPE`| No | `PR` | `.env` | GitHub notification environment type (production/staging/uat/dev/pr) | |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Consider clarifying environment type case sensitivity.
The default value shows PR (uppercase) but the description lists pr (lowercase) in the available options. Clarify whether these values are case-sensitive or normalize the documentation to be consistent.
📝 Proposed fix for consistency
-| `VORTEX_NOTIFY_GITHUB_ENVIRONMENT_TYPE`| No | `PR` | `.env` | GitHub notification environment type (production/staging/uat/dev/pr) |
+| `VORTEX_NOTIFY_GITHUB_ENVIRONMENT_TYPE`| No | `PR` | `.env` | GitHub notification environment type (production/staging/uat/dev/PR) |📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| | `VORTEX_NOTIFY_GITHUB_ENVIRONMENT_TYPE`| No | `PR` | `.env` | GitHub notification environment type (production/staging/uat/dev/pr) | | |
| | `VORTEX_NOTIFY_GITHUB_ENVIRONMENT_TYPE`| No | `PR` | `.env` | GitHub notification environment type (production/staging/uat/dev/PR) | |
🤖 Prompt for AI Agents
In @.vortex/docs/content/workflows/notifications/github.mdx at line 25, The doc
shows a mismatch in case for the environment type: the variable
VORTEX_NOTIFY_GITHUB_ENVIRONMENT_TYPE lists default `PR` but the allowed value
`pr` is lowercase; update the documentation to be consistent by either
normalizing the displayed values (e.g., use lowercase `pr` in the default and
options) or explicitly state the case sensitivity (e.g., "values are
case-insensitive; accepted values: production/staging/uat/dev/pr (default:
PR)"). Ensure the variable name VORTEX_NOTIFY_GITHUB_ENVIRONMENT_TYPE and the
set of allowed values are consistent and unambiguous.
| - Track deployment frequency | ||
| - Monitor release impact in real-time | ||
|
|
||
| ➡️ See [Workflows > Notifications > New Relic](notifications/newrelic) |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
find .vortex/docs/content -type f -name "*.mdx" -o -name "*.md" | head -30Repository: drevops/vortex
Length of output: 1439
🏁 Script executed:
# Get a better understanding of the directory structure
tree -L 4 .vortex/docs/content/workflows 2>/dev/null || find .vortex/docs/content/workflows -type d | sortRepository: drevops/vortex
Length of output: 607
🏁 Script executed:
# Check if notifications directory exists and where
find .vortex/docs/content -type d -name "notifications"Repository: drevops/vortex
Length of output: 102
🏁 Script executed:
sed -n '110,115p' .vortex/docs/content/workflows/releasing/README.mdxRepository: drevops/vortex
Length of output: 215
Fix the relative link path for New Relic notification documentation.
The link notifications/newrelic from workflows/releasing/README.mdx resolves to workflows/releasing/notifications/newrelic, which doesn't exist. The target file is at workflows/notifications/newrelic.mdx, so use ../notifications/newrelic instead.
🔧 Fix
-➡️ See [Workflows > Notifications > New Relic](notifications/newrelic)
+➡️ See [Workflows > Notifications > New Relic](../notifications/newrelic)📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| ➡️ See [Workflows > Notifications > New Relic](notifications/newrelic) | |
| ➡️ See [Workflows > Notifications > New Relic](../notifications/newrelic) |
🤖 Prompt for AI Agents
In @.vortex/docs/content/workflows/releasing/README.mdx at line 113, The link
target "notifications/newrelic" in the README (the arrowed link line) is
incorrect for the current document location; update the Markdown link target
from "notifications/newrelic" to "../notifications/newrelic" so it points to the
correct New Relic notification page.
Comment on lines
165
to
170
| ```gherkin | ||
| As a site visitor # Anonymous users | ||
| As a site administrator # Admin users | ||
| As a content editor # Content management users | ||
| As a authenticated user # Logged-in users | ||
| ``` |
There was a problem hiding this comment.
Grammar: use “an authenticated user.”
Tightens the Gherkin example wording.
✏️ Suggested edit
-As a authenticated user # Logged-in users
+As an authenticated user # Logged-in users🤖 Prompt for AI Agents
In @.vortex/docs/content/workflows/testing/behat.mdx around lines 165 - 170,
Replace the incorrect article in the Gherkin example: find the line "As a
authenticated user" in the Behat example block and change it to "As an
authenticated user" (update the text inside the fenced gherkin snippet so the
four lines read As a site visitor, As a site administrator, As a content editor,
As an authenticated user).
Comment on lines
34
to
38
| # Drush commands | ||
| ahoy drush cr # Clear cache | ||
| ahoy drush cex # Export configuration to code | ||
| ahoy drush cim # Import configuration from code | ||
| ahoy drush uli # Get one-time login link |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Add ahoy drush updatedb to the Drush task list.
Include the database update command (ideally before cim) so the quick-reference tasks reflect the recommended deployment order.
Based on learnings: Run 'ahoy drush updatedb' before importing configuration during deployment to ensure database schema is current.
🛠️ Suggested addition
# Drush commands
ahoy drush cr # Clear cache
ahoy drush cex # Export configuration to code
+ahoy drush updatedb # Apply database updates (run before config import when deploying)
ahoy drush cim # Import configuration from code
ahoy drush uli # Get one-time login link🤖 Prompt for AI Agents
In `@CLAUDE.md` around lines 34 - 38, The Drush task list is missing the database
update command; add "ahoy drush updatedb" into the list and place it before the
existing "ahoy drush cim" entry so the recommended deployment order runs
database updates prior to importing configuration (update the block that
currently contains "ahoy drush cr", "ahoy drush cex", "ahoy drush cim", "ahoy
drush uli" to include "ahoy drush updatedb" immediately before "ahoy drush
cim").
Member
Author
|
Member
Author
|
This comment has been minimized.
This comment has been minimized.
Member
Author
|
Member
Author
|
Member
Author
|
AlexSkrypnyk
force-pushed
the
feature/claude-testing-details
branch
from
d91c317 to
fdbec38
Compare
This comment has been minimized.
This comment has been minimized.
Member
Author
|
Member
Author
|
Member
Author
|
AlexSkrypnyk
force-pushed
the
feature/claude-testing-details
branch
from
fdbec38 to
d8193c0
Compare
Member
Author
|
This comment has been minimized.
This comment has been minimized.
Member
Author
|
Member
Author
|
AlexSkrypnyk
force-pushed
the
feature/claude-testing-details
branch
from
d8193c0 to
247c60b
Compare
Member
Author
|
This comment has been minimized.
This comment has been minimized.
Member
Author
|
Member
Author
|
AlexSkrypnyk
force-pushed
the
feature/claude-testing-details
branch
from
247c60b to
c226654
Compare
This comment has been minimized.
This comment has been minimized.
Member
Author
|
Member
Author
|
Member
Author
|
AlexSkrypnyk
force-pushed
the
feature/claude-testing-details
branch
from
c226654 to
f1345a6
Compare
This comment has been minimized.
This comment has been minimized.
Member
Author
|
Member
Author
|
Member
Author
|
There was a problem hiding this comment.
Actionable comments posted: 14
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
.vortex/tests/phpunit/Traits/ProcessTrait.php (1)
34-44:⚠️ Potential issue | 🟠 MajorGuard
GITHUB_TOKENassignment to avoid overriding inherited tokens.When
TEST_GITHUB_TOKENis unset, settingGITHUB_TOKENto''can override an inherited token from the parent process and suppress authenticated API calls. Use a conditional assignment instead.Suggested fix
$env += [ 'AHOY_CONFIRM_RESPONSE' => 'y', 'AHOY_CONFIRM_WAIT_SKIP' => 1, // Credentials for the test container registry to allow fetching public // images to overcome the throttle limit of Docker Hub, and also used // for pushing images during the build. 'VORTEX_CONTAINER_REGISTRY_USER' => getenv('TEST_VORTEX_CONTAINER_REGISTRY_USER') ?: '', 'VORTEX_CONTAINER_REGISTRY_PASS' => getenv('TEST_VORTEX_CONTAINER_REGISTRY_PASS') ?: '', - // GitHub token for API calls to avoid rate limiting. - 'GITHUB_TOKEN' => getenv('TEST_GITHUB_TOKEN') ?: '', ]; + + $testGithubToken = getenv('TEST_GITHUB_TOKEN'); + if ($testGithubToken !== false && $testGithubToken !== '') { + // GitHub token for API calls to avoid rate limiting. + $env += ['GITHUB_TOKEN' => $testGithubToken]; + }.vortex/docs/content/contributing/maintenance/tests.mdx (1)
217-223:⚠️ Potential issue | 🟠 MajorChange step 6 to tag/push the test image, not demo.
The "Updating test database container image" section seedstest-11.x:latestin step 5 but step 6 tags/pushes fromdemo-11.x:latestwhich doesn't exist in this workflow. Usetest-11.xas the source image in both docker tag commands.Suggested change
- docker tag drevops/vortex-dev-mariadb-drupal-data-demo-11.x:latest drevops/vortex-dev-mariadb-drupal-data-demo-destination-11.x:vortex-dev-database-ii - docker push drevops/vortex-dev-mariadb-drupal-data-demo-destination-11.x:vortex-dev-database-ii - - docker tag drevops/vortex-dev-mariadb-drupal-data-demo-11.x:latest drevops/vortex-dev-mariadb-drupal-data-demo-destination-11.x:vortex-dev-didi-database-fi - docker push drevops/vortex-dev-mariadb-drupal-data-demo-destination-11.x:vortex-dev-didi-database-fi + docker tag drevops/vortex-dev-mariadb-drupal-data-test-11.x:latest drevops/vortex-dev-mariadb-drupal-data-test-destination-11.x:vortex-dev-database-ii + docker push drevops/vortex-dev-mariadb-drupal-data-test-destination-11.x:vortex-dev-database-ii + + docker tag drevops/vortex-dev-mariadb-drupal-data-test-11.x:latest drevops/vortex-dev-mariadb-drupal-data-test-destination-11.x:vortex-dev-didi-database-fi + docker push drevops/vortex-dev-mariadb-drupal-data-test-destination-11.x:vortex-dev-didi-database-fi
🤖 Fix all issues with AI agents
In @.vortex/docs/content/deployment/artifact.mdx:
- Around line 25-33: Update the description for
VORTEX_DEPLOY_ARTIFACT_GIT_USER_NAME in the table to use the single-word term
"username" instead of "user name" — change "Git user name for commits" to "Git
username for commits" (leave VORTEX_DEPLOY_ARTIFACT_GIT_USER_EMAIL unchanged
unless you want the same style applied there).
In @.vortex/docs/content/development/behat.mdx:
- Around line 62-66: In the docker-compose TabItem example the Behat CLI
invocation contains an extra separator ("-- --definitions=l"); update the
command string inside the TabItem with value "docker-compose" to use a single
options form (remove the redundant "--") so it reads the proper Behat invocation
(e.g., vendor/bin/behat --definitions=l) to fix the duplicate `--` issue.
In @.vortex/docs/content/development/faqs.mdx:
- Around line 231-238: The JSON example under extra.patches for
"drupal/somepackage" is invalid because the "Remote patch description" and
"Local patch description" properties are missing a comma separator; edit the
snippet in faqs.mdx to insert a comma after the remote URL line so the two
entries ("Remote patch description" and "Local patch description") form valid
JSON object syntax under the patches/drupal/somepackage block.
In @.vortex/docs/content/development/variables.mdx:
- Around line 20-22: Reword the awkward sentence under the "Runtime Variables"
section: replace the two-sentence fragment that reads "Runtime Variables can be
changed during the project lifecycle to alter script behavior. For example,
changing how deployment behaves or skipping a certain code branch deployment
within CI." with a tighter phrasing that clearly states intent (e.g., "Runtime
variables can be changed during the project lifecycle to alter script behavior,
such as modifying deployment behavior or skipping a deployment branch in CI").
Update the text around the "Runtime Variables" heading and ensure punctuation
and capitalization remain consistent.
- Line 309: The VORTEX_NOTIFY_NEWRELIC_USER_KEY table cell contains inline
numbered steps that are hard to scan; update the description for
VORTEX_NOTIFY_NEWRELIC_USER_KEY to replace the inline "1. 2. 3." sequence with a
simple, vertically separated list (e.g., using Markdown list or <br/>- style
bullets) so each step (log in, click profile, go to API keys, create/copy User
key, note NRAK-... format) appears on its own line; keep the existing links and
the reference to `${NEWRELIC_USER_KEY}` and `scripts/vortex/notify-newrelic.sh`
intact.
In @.vortex/docs/content/faqs.mdx:
- Around line 6-7: The FAQ uses both "automations" and "automation scripts"
inconsistently; pick one term (e.g., "automation scripts") and replace
occurrences to match across the document, specifically update the phrase in the
excerpt containing "CI pipelines, tooling, automations, deployment scripts,
hosting configurations" and the later occurrence around lines referenced (the
block mentioning "automation scripts"/"automations"); ensure the chosen term is
used uniformly in both places and in any other instances in the same file.
In @.vortex/docs/content/releasing/gitflow.mdx:
- Around line 111-121: The "Expected release outcome" text is inconsistent with
the Mermaid diagram's v-prefixed tags; update the wording in that section so tag
references use the v-prefix used in the diagram — e.g., change occurrences of
`X.Y.Z` to `vX.Y.Z` in the sentences mentioning the release tag and the `HEAD`
of `main` (leave `release/X.Y.Z` branch naming as-is if you intend branches
without the v), and ensure references to the tag in lines describing the `HEAD`
of `main` and existence in `develop` explicitly use `vX.Y.Z`.
In @.vortex/docs/cspell.json:
- Around line 22-23: The cspell word list is not alphabetical: "automations"
appears before "apikey"; reorder the entries so "apikey" comes before
"automations". Locate the array entry containing "apikey" and "automations" and
swap or move "automations" to follow "apikey" to restore alphabetical order.
In @.vortex/installer/CLAUDE.md:
- Around line 30-39: The fenced code block showing the directory tree (the lines
starting with "tests/Fixtures/install/" and the opening "```" fence) is
unlabeled and triggers MD040; fix it by changing the opening fence from "```" to
"```text" (or another appropriate language tag) so the block is labeled and
markdownlint no longer flags it.
In @.vortex/tests/.markdownlint.yaml:
- Around line 17-18: Update the MD029 rule's documentation URL to the same
versioned reference used elsewhere in the file: replace the `/blob/main/` link
for MD029 with the `/blob/v0.38.0/` (or the specific version used in other rule
links) so the MD029 entry's link is consistent and stable; locate the MD029:
false entry and adjust its associated URL to the versioned path.
In @.vortex/tests/CLAUDE.md:
- Around line 44-53: The negative assertion in the STEPS array is shown with
extra spaces ("- Unwanted output") which is misleading; update the example
in the STEPS declaration (and its comment) to use the correct BATS negative
assertion prefix "- " (dash followed by a single space), e.g. change the entry
referenced by STEPS and the inline comment so it reads "- Unwanted output" to
match the actual parser rule used by run_steps.
In `@docs/deployment.md`:
- Around line 8-38: The file contains a duplicate "## Hosting provider" heading
which triggers markdownlint MD024; locate the second occurrence of the heading
text "## Hosting provider" and either remove it or rename it to a unique heading
(for example "## Hosting provider (Acquia)" or "## Hosting provider — Additional
info") and update any nearby anchor/comment markers if needed so the document
stays consistent; ensure the heading text is unique to resolve MD024 without
changing the surrounding content.
In `@docs/testing.md`:
- Around line 222-233: The ordered list numbering in the Gherkin example uses
"3." but must restart at "1." to satisfy markdownlint rule MD029; update the
list item label before the code block (the line currently starting with "3. Test
all visible fields") to "1. Test all visible fields" so the document uses the
1/1/1 style; ensure only the numeric prefix is changed and the Gherkin block
(title/body/field_tags lines) remains unchanged.
- Around line 198-199: Change the heading text "Content type testing process" to
"Content-type testing process" for consistent hyphenation; locate the header
string in docs/testing.md (the line currently reading "### Content type testing
process") and update it to include the hyphen.
Comment on lines
+25
to
+33
| | Variable | Required | Default | Location | Description | | ||
| |----------|----------|---------|----------|-------------| | ||
| | `VORTEX_DEPLOY_ARTIFACT_GIT_REMOTE` | **Yes** | | `.env` | Remote repository URL for the artifact | | ||
| | `VORTEX_DEPLOY_ARTIFACT_ROOT` | No | Current directory | `.env` | Root directory for artifact creation | | ||
| | `VORTEX_DEPLOY_ARTIFACT_SRC` | No | Current directory | `.env` | Source directory to package | | ||
| | `VORTEX_DEPLOY_ARTIFACT_DST` | No | `.artifact` | `.env` | Destination directory for artifact | | ||
| | `VORTEX_DEPLOY_ARTIFACT_GIT_USER_NAME` | **Yes** | | CI | Git user name for commits | | ||
| | `VORTEX_DEPLOY_ARTIFACT_GIT_USER_EMAIL` | **Yes** | | CI | Git user email for commits | | ||
| | `VORTEX_DEPLOY_ARTIFACT_LOG` | No | | `.env` | Log file path | |
There was a problem hiding this comment.
Use “username” (one word) for consistency.
Line 31 reads “Git user name”; “Git username” is the common term in docs and UI.
✏️ Suggested edit
-| `VORTEX_DEPLOY_ARTIFACT_GIT_USER_NAME` | **Yes** | | CI | Git user name for commits |
+| `VORTEX_DEPLOY_ARTIFACT_GIT_USER_NAME` | **Yes** | | CI | Git username for commits |📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| | Variable | Required | Default | Location | Description | | |
| |----------|----------|---------|----------|-------------| | |
| | `VORTEX_DEPLOY_ARTIFACT_GIT_REMOTE` | **Yes** | | `.env` | Remote repository URL for the artifact | | |
| | `VORTEX_DEPLOY_ARTIFACT_ROOT` | No | Current directory | `.env` | Root directory for artifact creation | | |
| | `VORTEX_DEPLOY_ARTIFACT_SRC` | No | Current directory | `.env` | Source directory to package | | |
| | `VORTEX_DEPLOY_ARTIFACT_DST` | No | `.artifact` | `.env` | Destination directory for artifact | | |
| | `VORTEX_DEPLOY_ARTIFACT_GIT_USER_NAME` | **Yes** | | CI | Git user name for commits | | |
| | `VORTEX_DEPLOY_ARTIFACT_GIT_USER_EMAIL` | **Yes** | | CI | Git user email for commits | | |
| | `VORTEX_DEPLOY_ARTIFACT_LOG` | No | | `.env` | Log file path | | |
| | Variable | Required | Default | Location | Description | | |
| |----------|----------|---------|----------|-------------| | |
| | `VORTEX_DEPLOY_ARTIFACT_GIT_REMOTE` | **Yes** | | `.env` | Remote repository URL for the artifact | | |
| | `VORTEX_DEPLOY_ARTIFACT_ROOT` | No | Current directory | `.env` | Root directory for artifact creation | | |
| | `VORTEX_DEPLOY_ARTIFACT_SRC` | No | Current directory | `.env` | Source directory to package | | |
| | `VORTEX_DEPLOY_ARTIFACT_DST` | No | `.artifact` | `.env` | Destination directory for artifact | | |
| | `VORTEX_DEPLOY_ARTIFACT_GIT_USER_NAME` | **Yes** | | CI | Git username for commits | | |
| | `VORTEX_DEPLOY_ARTIFACT_GIT_USER_EMAIL` | **Yes** | | CI | Git user email for commits | | |
| | `VORTEX_DEPLOY_ARTIFACT_LOG` | No | | `.env` | Log file path | |
🧰 Tools
🪛 LanguageTool
[style] ~31-~31: It’s more common nowadays to write this noun as one word.
Context: ...T_GIT_USER_NAME| **Yes** | | CI | Git user name for commits | |VORTEX_DEPLOY_ARTIFACT...
(RECOMMENDED_COMPOUNDS)
🤖 Prompt for AI Agents
In @.vortex/docs/content/deployment/artifact.mdx around lines 25 - 33, Update
the description for VORTEX_DEPLOY_ARTIFACT_GIT_USER_NAME in the table to use the
single-word term "username" instead of "user name" — change "Git user name for
commits" to "Git username for commits" (leave
VORTEX_DEPLOY_ARTIFACT_GIT_USER_EMAIL unchanged unless you want the same style
applied there).
Comment on lines
+231
to
+238
| ```json | ||
| "extra": { | ||
| "patches": { | ||
| "drupal/somepackage": { | ||
| "Remote patch description": "https://www.drupal.org/files/issues/issue.patch" | ||
| "Local patch description": "patches/package-description.patch" | ||
| } | ||
| } |
There was a problem hiding this comment.
Fix invalid JSON in patch example (missing comma).
The JSON snippet under "How to add patches for Drupal modules" is missing a comma between properties, which makes it invalid if copied.
✅ Suggested fix
"drupal/somepackage": {
- "Remote patch description": "https://www.drupal.org/files/issues/issue.patch"
+ "Remote patch description": "https://www.drupal.org/files/issues/issue.patch",
"Local patch description": "patches/package-description.patch"
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| ```json | |
| "extra": { | |
| "patches": { | |
| "drupal/somepackage": { | |
| "Remote patch description": "https://www.drupal.org/files/issues/issue.patch" | |
| "Local patch description": "patches/package-description.patch" | |
| } | |
| } |
🤖 Prompt for AI Agents
In @.vortex/docs/content/development/faqs.mdx around lines 231 - 238, The JSON
example under extra.patches for "drupal/somepackage" is invalid because the
"Remote patch description" and "Local patch description" properties are missing
a comma separator; edit the snippet in faqs.mdx to insert a comma after the
remote URL line so the two entries ("Remote patch description" and "Local patch
description") form valid JSON object syntax under the patches/drupal/somepackage
block.
| | <a id="vortex_notify_newrelic_sha"></a>`VORTEX_NOTIFY_NEWRELIC_SHA` | New Relic notification git commit SHA. | `${VORTEX_NOTIFY_SHA}` | `scripts/vortex/notify-newrelic.sh` | | ||
| | <a id="vortex_notify_newrelic_user"></a>`VORTEX_NOTIFY_NEWRELIC_USER` | New Relic notification user performing deployment. | `Deployment robot` | `scripts/vortex/notify-newrelic.sh` | | ||
| | <a id="vortex_notify_newrelic_user_key"></a>`VORTEX_NOTIFY_NEWRELIC_USER_KEY` | New Relic notification User API Key.<br/><br/>To obtain your User API Key: `1`. Log in to New Relic `2`. Click on your profile icon (bottom left) `3`. Go to "API keys" `4`. Create or copy an existing "User key" `5`. The key format is: NRAK-XXXXXXXXXXXXXXXXXXXXXX<br/><br/>@see https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/#user-key @see https://www.vortextemplate.com/docs/workflows/notifications#new-relic | `${NEWRELIC_USER_KEY}` | `scripts/vortex/notify-newrelic.sh` | | ||
| | <a id="vortex_notify_newrelic_user_key"></a>`VORTEX_NOTIFY_NEWRELIC_USER_KEY` | New Relic notification User API Key.<br/><br/>To obtain your User API Key: `1`. Log in to New Relic `2`. Click on your profile icon (bottom left) `3`. Go to "API keys" `4`. Create or copy an existing "User key" `5`. The key format is: NRAK-XXXXXXXXXXXXXXXXXXXXXX<br/><br/>@see https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/#user-key @see https://www.vortextemplate.com/docs/deployment/notifications#new-relic | `${NEWRELIC_USER_KEY}` | `scripts/vortex/notify-newrelic.sh` | |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Make the “User API Key” steps easier to scan.
The inline numbered steps are hard to read in a table cell; a simple list improves clarity.
✏️ Suggested formatting
-| <a id="vortex_notify_newrelic_user_key"></a>`VORTEX_NOTIFY_NEWRELIC_USER_KEY` | New Relic notification User API Key.<br/><br/>To obtain your User API Key: `1`. Log in to New Relic `2`. Click on your profile icon (bottom left) `3`. Go to "API keys" `4`. Create or copy an existing "User key" `5`. The key format is: NRAK-XXXXXXXXXXXXXXXXXXXXXX<br/><br/>@see https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/#user-key `@see` https://www.vortextemplate.com/docs/deployment/notifications#new-relic | `${NEWRELIC_USER_KEY}` | `scripts/vortex/notify-newrelic.sh` |
+| <a id="vortex_notify_newrelic_user_key"></a>`VORTEX_NOTIFY_NEWRELIC_USER_KEY` | New Relic notification User API Key.<br/><br/>To obtain your User API Key:<br/>1. Log in to New Relic.<br/>2. Click your profile icon (bottom left).<br/>3. Go to "API keys".<br/>4. Create or copy an existing "User key".<br/>5. Key format: NRAK-XXXXXXXXXXXXXXXXXXXXXX<br/><br/>@see https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/#user-key `@see` https://www.vortextemplate.com/docs/deployment/notifications#new-relic | `${NEWRELIC_USER_KEY}` | `scripts/vortex/notify-newrelic.sh` |📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| | <a id="vortex_notify_newrelic_user_key"></a>`VORTEX_NOTIFY_NEWRELIC_USER_KEY` | New Relic notification User API Key.<br/><br/>To obtain your User API Key: `1`. Log in to New Relic `2`. Click on your profile icon (bottom left) `3`. Go to "API keys" `4`. Create or copy an existing "User key" `5`. The key format is: NRAK-XXXXXXXXXXXXXXXXXXXXXX<br/><br/>@see https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/#user-key @see https://www.vortextemplate.com/docs/deployment/notifications#new-relic | `${NEWRELIC_USER_KEY}` | `scripts/vortex/notify-newrelic.sh` | | |
| | <a id="vortex_notify_newrelic_user_key"></a>`VORTEX_NOTIFY_NEWRELIC_USER_KEY` | New Relic notification User API Key.<br/><br/>To obtain your User API Key:<br/>1. Log in to New Relic.<br/>2. Click your profile icon (bottom left).<br/>3. Go to "API keys".<br/>4. Create or copy an existing "User key".<br/>5. Key format: NRAK-XXXXXXXXXXXXXXXXXXXXXX<br/><br/>@see https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/#user-key `@see` https://www.vortextemplate.com/docs/deployment/notifications#new-relic | `${NEWRELIC_USER_KEY}` | `scripts/vortex/notify-newrelic.sh` | |
🤖 Prompt for AI Agents
In @.vortex/docs/content/development/variables.mdx at line 309, The
VORTEX_NOTIFY_NEWRELIC_USER_KEY table cell contains inline numbered steps that
are hard to scan; update the description for VORTEX_NOTIFY_NEWRELIC_USER_KEY to
replace the inline "1. 2. 3." sequence with a simple, vertically separated list
(e.g., using Markdown list or <br/>- style bullets) so each step (log in, click
profile, go to API keys, create/copy User key, note NRAK-... format) appears on
its own line; keep the existing links and the reference to
`${NEWRELIC_USER_KEY}` and `scripts/vortex/notify-newrelic.sh` intact.
Comment on lines
+17
to
+18
| # MD029/ol-prefix : Ordered list item prefix : https://github.com/DavidAnson/markdownlint/blob/main/doc/md029.md | ||
| MD029: false |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Inconsistent documentation link version.
The URL for MD029 references /blob/main/ while all other rules in this file reference a specific version /blob/v0.38.0/. Consider using a versioned link for consistency and stability.
📝 Suggested fix
-# MD029/ol-prefix : Ordered list item prefix : https://github.com/DavidAnson/markdownlint/blob/main/doc/md029.md
+# MD029/ol-prefix : Ordered list item prefix : https://github.com/DavidAnson/markdownlint/blob/v0.38.0/doc/md029.md
MD029: false📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| # MD029/ol-prefix : Ordered list item prefix : https://github.com/DavidAnson/markdownlint/blob/main/doc/md029.md | |
| MD029: false | |
| # MD029/ol-prefix : Ordered list item prefix : https://github.com/DavidAnson/markdownlint/blob/v0.38.0/doc/md029.md | |
| MD029: false |
🤖 Prompt for AI Agents
In @.vortex/tests/.markdownlint.yaml around lines 17 - 18, Update the MD029
rule's documentation URL to the same versioned reference used elsewhere in the
file: replace the `/blob/main/` link for MD029 with the `/blob/v0.38.0/` (or the
specific version used in other rule links) so the MD029 entry's link is
consistent and stable; locate the MD029: false entry and adjust its associated
URL to the versioned path.
Comment on lines
+44
to
+53
| declare -a STEPS=( | ||
| "@drush -y status # 0 # success" # Mock | ||
| "Expected output" # Must contain | ||
| "- Unwanted output" # Must NOT contain | ||
| ) | ||
|
|
||
| mocks="$(run_steps "setup")" | ||
| # ... run code ... | ||
| run_steps "assert" "${mocks}" | ||
| ``` |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Clarify the BATS negative assertion prefix format.
Line 47 shows "- Unwanted output" with multiple spaces, but the actual prefix is "- " (dash followed by a single space). The extra spaces might confuse readers about the exact format required.
📝 Proposed clarification
declare -a STEPS=(
"@drush -y status # 0 # success" # Mock
"Expected output" # Must contain
- "- Unwanted output" # Must NOT contain
+ "- Unwanted output" # Must NOT contain
)🤖 Prompt for AI Agents
In @.vortex/tests/CLAUDE.md around lines 44 - 53, The negative assertion in the
STEPS array is shown with extra spaces ("- Unwanted output") which is
misleading; update the example in the STEPS declaration (and its comment) to use
the correct BATS negative assertion prefix "- " (dash followed by a single
space), e.g. change the entry referenced by STEPS and the inline comment so it
reads "- Unwanted output" to match the actual parser rule used by run_steps.
Comment on lines
+8
to
+38
| ## Hosting provider | ||
|
|
||
| Once PR is closed, the environment will be automatically removed. | ||
| This project is hosted on [Acquia Cloud](https://www.acquia.com/products/drupal-cloud). | ||
|
|
||
| [//]: # (#;< HOSTING_ACQUIA) | ||
| See [Acquia hosting documentation](https://www.vortextemplate.com/docs/hosting/acquia) | ||
| for setup and configuration details. | ||
|
|
||
| ### Deployment workflow | ||
|
|
||
| GitHub is a primary code repository for this project (aka "source repository"). | ||
| Acquia Cloud is a hosting provider for this project and it also has a git | ||
| repository (aka "destination repository"). | ||
|
|
||
| The website gets deployed using artifact built on CI and pushed to Acquia Cloud. | ||
|
|
||
| There are 2 types of deployments: feature branches and release tags. They are | ||
| exactly the same except for the resulting branch name on Acquia Cloud (see | ||
| below). | ||
|
|
||
| ## Setup | ||
|
|
||
| 1. Create a Deployer user (deployer@yourcompany.com) account in Acquia. | ||
| 2. Add this user to Acquia Cloud application with a role that allows to push | ||
| code and use Cloud API. | ||
| 3. Login with Deployer user and go to Acquia Cloud UI->Account->Credentials-> | ||
| Copy email and key from section "Cloud API". | ||
| 4. SSH into non-production server and run `drush ac-api-login`. Enter copied | ||
| email and key when prompted. This will store credentials | ||
| to `$HOME/.acquia/cloudapi.conf`and they will not need to be entered again. | ||
| This allows to use Cloud API drush commands within hooks. | ||
| 5. Create SSH key (use `deployer+yourproject@yourcompany.com` as an email to | ||
| distinguish SSH keys) and add it to this user. This key cannot be re-used | ||
| between projects! | ||
| 6. Login to CircleCI, go to Settings->SSH Permissions->Add SSH Key and paste * | ||
| private* key. This allows to push the code from CI to Acquia git repository. | ||
| 7. Copy SHH key fingerprint (looks | ||
| like `16:02:e3:ca:33:04:82:58:e8:e9:3e:5d:82:17:86:b1`) and replace it | ||
| inside `.circleci/config.yml`. | ||
|
|
||
| ## Deployment workflow | ||
|
|
||
| 1. Developer updates DB in the Acquia Cloud environment by copying PROD database | ||
| to required environment. | ||
| 2. Developer pushes code update to the GitHub branch. | ||
| 3. CI system picks-up the update and does the following: | ||
| 4. Builds a website using production DB. | ||
| 5. Runs code standard checks and Behat tests on the built website. | ||
| 6. Creates a deployment artifact (project files to be pushed to Acquia Cloud | ||
| 1. Code is pushed to GitHub (source repository). | ||
| 2. CI builds and tests the code. | ||
| 3. On success, CI builds an artifact and pushes to Acquia Cloud (destination | ||
| repository). | ||
| 7. Pushes created artifact to the Acquia Cloud repository: | ||
| - for feature-based branches (i.e. `feature/ABC-123` or `bugfix/ABC-123`) | ||
| the code is pushed to the branch with exactly the same name. | ||
| - for release deployments, which are tag-based (i.e. `0.1.4`), the code is | ||
| pushed to the branch `deployment/[tag]` (i.e. `deployment/0.1.4`). | ||
| 8. Acquia Cloud picks up recent push to the repository and | ||
| runs [post code update hooks](hooks/dev/post-code-update) on the environments | ||
| where code is already deployed. | ||
| OR | ||
| 9. If the branch has not been deployed into any Acquia Cloud environment yet and | ||
| the developer starts the deployment, Acquia Cloud | ||
| runs [post code deploy hooks](hooks/dev/post-code-deploy) on the environment | ||
| where code is being deployed. | ||
|
|
||
| ### Release outcome | ||
|
|
||
| 1. Release branch exists as `deployment/X.Y.Z` in remote GitHub repository. | ||
| 2. Release tag exists as `X.Y.Z` in remote GitHub repository. | ||
| 3. The `HEAD` of the `main` branch has `X.Y.Z` tag assigned. | ||
| 4. The hash of the `HEAD` of the `main` branch exists in the `develop` branch. | ||
| This is to ensure that everything pushed to `main` exists in `developed` (in | ||
| case if `main` had any hot-fixes that not yet have been merged to `develop`). | ||
| 5. There are no PRs in GitHub related to releases. | ||
| 6. Release branch is available on Acquia Cloud as `deployment/X.Y.Z` branch. | ||
| Note: we are building release branches on Acquia Cloud out of tags in GitHub. | ||
| 7. Release branch `deployment/X.Y.Z` is deployed into PROD environment. Note: we | ||
| are NOT deploying tags to Acquia Cloud PROD. | ||
|
|
||
| ### Important | ||
|
|
||
| Since Acquia Cloud becomes a destination repository, the following rules MUST be | ||
| followed by all developers: | ||
|
|
||
| 1. There should be no direct access to Acquia Cloud repository for anyone except | ||
| for project Technical Lead and Deployer user. | ||
| 2. There should be no pushes to Acquia Cloud repository. | ||
| 3. There may be `main` or `develop` branch in Acquia Cloud repository. | ||
| 4. Technical Lead is expected to regularly cleanup `feature/*` and `bugfix/*` | ||
| branches in Acquia Cloud repository. | ||
| 4. Acquia Cloud runs deployment hooks. | ||
|
|
||
| ### Branch naming on Acquia Cloud | ||
|
|
||
| - Feature branches (`feature/ABC-123`) → same name on Acquia | ||
| - Release tags (`0.1.4`) → `deployment/0.1.4` branch on Acquia | ||
|
|
||
| ### Important rules | ||
|
|
||
| - No direct pushes to Acquia Cloud repository. | ||
| - Only Technical Lead and Deployer user should have access to Acquia repository. | ||
| - Technical Lead should regularly clean up `feature/*` and `bugfix/*` branches. | ||
|
|
||
| [//]: # (#;> HOSTING_ACQUIA) | ||
|
|
||
| [//]: # (#;< HOSTING_LAGOON) | ||
|
|
||
| ## Database refresh in Lagoon environments | ||
| ## Hosting provider |
There was a problem hiding this comment.
Resolve duplicate “Hosting provider” headings (MD024).
Line 38 repeats the heading from Line 8 and triggers the markdownlint warning. Consider making the headings unique.
♻️ Suggested fix
-## Hosting provider
+## Hosting provider (Acquia)
...
-## Hosting provider
+## Hosting provider (Lagoon)📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| ## Hosting provider | |
| Once PR is closed, the environment will be automatically removed. | |
| This project is hosted on [Acquia Cloud](https://www.acquia.com/products/drupal-cloud). | |
| [//]: # (#;< HOSTING_ACQUIA) | |
| See [Acquia hosting documentation](https://www.vortextemplate.com/docs/hosting/acquia) | |
| for setup and configuration details. | |
| ### Deployment workflow | |
| GitHub is a primary code repository for this project (aka "source repository"). | |
| Acquia Cloud is a hosting provider for this project and it also has a git | |
| repository (aka "destination repository"). | |
| The website gets deployed using artifact built on CI and pushed to Acquia Cloud. | |
| There are 2 types of deployments: feature branches and release tags. They are | |
| exactly the same except for the resulting branch name on Acquia Cloud (see | |
| below). | |
| ## Setup | |
| 1. Create a Deployer user (deployer@yourcompany.com) account in Acquia. | |
| 2. Add this user to Acquia Cloud application with a role that allows to push | |
| code and use Cloud API. | |
| 3. Login with Deployer user and go to Acquia Cloud UI->Account->Credentials-> | |
| Copy email and key from section "Cloud API". | |
| 4. SSH into non-production server and run `drush ac-api-login`. Enter copied | |
| email and key when prompted. This will store credentials | |
| to `$HOME/.acquia/cloudapi.conf`and they will not need to be entered again. | |
| This allows to use Cloud API drush commands within hooks. | |
| 5. Create SSH key (use `deployer+yourproject@yourcompany.com` as an email to | |
| distinguish SSH keys) and add it to this user. This key cannot be re-used | |
| between projects! | |
| 6. Login to CircleCI, go to Settings->SSH Permissions->Add SSH Key and paste * | |
| private* key. This allows to push the code from CI to Acquia git repository. | |
| 7. Copy SHH key fingerprint (looks | |
| like `16:02:e3:ca:33:04:82:58:e8:e9:3e:5d:82:17:86:b1`) and replace it | |
| inside `.circleci/config.yml`. | |
| ## Deployment workflow | |
| 1. Developer updates DB in the Acquia Cloud environment by copying PROD database | |
| to required environment. | |
| 2. Developer pushes code update to the GitHub branch. | |
| 3. CI system picks-up the update and does the following: | |
| 4. Builds a website using production DB. | |
| 5. Runs code standard checks and Behat tests on the built website. | |
| 6. Creates a deployment artifact (project files to be pushed to Acquia Cloud | |
| 1. Code is pushed to GitHub (source repository). | |
| 2. CI builds and tests the code. | |
| 3. On success, CI builds an artifact and pushes to Acquia Cloud (destination | |
| repository). | |
| 7. Pushes created artifact to the Acquia Cloud repository: | |
| - for feature-based branches (i.e. `feature/ABC-123` or `bugfix/ABC-123`) | |
| the code is pushed to the branch with exactly the same name. | |
| - for release deployments, which are tag-based (i.e. `0.1.4`), the code is | |
| pushed to the branch `deployment/[tag]` (i.e. `deployment/0.1.4`). | |
| 8. Acquia Cloud picks up recent push to the repository and | |
| runs [post code update hooks](hooks/dev/post-code-update) on the environments | |
| where code is already deployed. | |
| OR | |
| 9. If the branch has not been deployed into any Acquia Cloud environment yet and | |
| the developer starts the deployment, Acquia Cloud | |
| runs [post code deploy hooks](hooks/dev/post-code-deploy) on the environment | |
| where code is being deployed. | |
| ### Release outcome | |
| 1. Release branch exists as `deployment/X.Y.Z` in remote GitHub repository. | |
| 2. Release tag exists as `X.Y.Z` in remote GitHub repository. | |
| 3. The `HEAD` of the `main` branch has `X.Y.Z` tag assigned. | |
| 4. The hash of the `HEAD` of the `main` branch exists in the `develop` branch. | |
| This is to ensure that everything pushed to `main` exists in `developed` (in | |
| case if `main` had any hot-fixes that not yet have been merged to `develop`). | |
| 5. There are no PRs in GitHub related to releases. | |
| 6. Release branch is available on Acquia Cloud as `deployment/X.Y.Z` branch. | |
| Note: we are building release branches on Acquia Cloud out of tags in GitHub. | |
| 7. Release branch `deployment/X.Y.Z` is deployed into PROD environment. Note: we | |
| are NOT deploying tags to Acquia Cloud PROD. | |
| ### Important | |
| Since Acquia Cloud becomes a destination repository, the following rules MUST be | |
| followed by all developers: | |
| 1. There should be no direct access to Acquia Cloud repository for anyone except | |
| for project Technical Lead and Deployer user. | |
| 2. There should be no pushes to Acquia Cloud repository. | |
| 3. There may be `main` or `develop` branch in Acquia Cloud repository. | |
| 4. Technical Lead is expected to regularly cleanup `feature/*` and `bugfix/*` | |
| branches in Acquia Cloud repository. | |
| 4. Acquia Cloud runs deployment hooks. | |
| ### Branch naming on Acquia Cloud | |
| - Feature branches (`feature/ABC-123`) → same name on Acquia | |
| - Release tags (`0.1.4`) → `deployment/0.1.4` branch on Acquia | |
| ### Important rules | |
| - No direct pushes to Acquia Cloud repository. | |
| - Only Technical Lead and Deployer user should have access to Acquia repository. | |
| - Technical Lead should regularly clean up `feature/*` and `bugfix/*` branches. | |
| [//]: # (#;> HOSTING_ACQUIA) | |
| [//]: # (#;< HOSTING_LAGOON) | |
| ## Database refresh in Lagoon environments | |
| ## Hosting provider | |
| ## Hosting provider (Acquia) | |
| This project is hosted on [Acquia Cloud](https://www.acquia.com/products/drupal-cloud). | |
| See [Acquia hosting documentation](https://www.vortextemplate.com/docs/hosting/acquia) | |
| for setup and configuration details. | |
| ### Deployment workflow | |
| 1. Code is pushed to GitHub (source repository). | |
| 2. CI builds and tests the code. | |
| 3. On success, CI builds an artifact and pushes to Acquia Cloud (destination | |
| repository). | |
| 4. Acquia Cloud runs deployment hooks. | |
| ### Branch naming on Acquia Cloud | |
| - Feature branches (`feature/ABC-123`) → same name on Acquia | |
| - Release tags (`0.1.4`) → `deployment/0.1.4` branch on Acquia | |
| ### Important rules | |
| - No direct pushes to Acquia Cloud repository. | |
| - Only Technical Lead and Deployer user should have access to Acquia repository. | |
| - Technical Lead should regularly clean up `feature/*` and `bugfix/*` branches. | |
| [//]: # (#;> HOSTING_ACQUIA) | |
| [//]: # (#;< HOSTING_LAGOON) | |
| ## Hosting provider (Lagoon) |
🧰 Tools
🪛 markdownlint-cli2 (0.20.0)
[warning] 38-38: Multiple headings with the same content
(MD024, no-duplicate-heading)
🤖 Prompt for AI Agents
In `@docs/deployment.md` around lines 8 - 38, The file contains a duplicate "##
Hosting provider" heading which triggers markdownlint MD024; locate the second
occurrence of the heading text "## Hosting provider" and either remove it or
rename it to a unique heading (for example "## Hosting provider (Acquia)" or "##
Hosting provider — Additional info") and update any nearby anchor/comment
markers if needed so the document stays consistent; ensure the heading text is
unique to resolve MD024 without changing the surrounding content.
Comment on lines
+198
to
+199
| ### Content type testing process | ||
|
|
There was a problem hiding this comment.
Hyphenate the heading for consistency.
“Content-type testing process” reads cleaner in this context.
✏️ Suggested tweak
-### Content type testing process
+### Content-type testing process📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| ### Content type testing process | |
| ### Content-type testing process | |
🧰 Tools
🪛 LanguageTool
[grammar] ~198-~198: Use a hyphen to join words.
Context: ...the "navigation" region ``` ### Content type testing process When creating comp...
(QB_NEW_EN_HYPHEN)
🤖 Prompt for AI Agents
In `@docs/testing.md` around lines 198 - 199, Change the heading text "Content
type testing process" to "Content-type testing process" for consistent
hyphenation; locate the header string in docs/testing.md (the line currently
reading "### Content type testing process") and update it to include the hyphen.
Comment on lines
+222
to
+233
| 3. Test all visible fields | ||
|
|
||
| ```gherkin | ||
| Scenario: View complete content with all fields | ||
| Given "page" content: | ||
| | title | body | field_tags | | ||
| | [TEST] Complete Page Test | [TEST] This is the body text. | [TEST] Topic 1 | | ||
| When I visit "[TEST] Complete Page Test" | ||
| Then I should see "[TEST] Complete Page Test" | ||
| And I should see "[TEST] This is the body text." | ||
| And I should see "[TEST] Topic 1" | ||
| ``` |
There was a problem hiding this comment.
Use 1. for ordered list items to satisfy markdownlint (MD029).
Line 222 should restart with 1. per the 1/1/1 style.
🔧 Suggested fix
-3. Test all visible fields
+1. Test all visible fields🧰 Tools
🪛 markdownlint-cli2 (0.20.0)
[warning] 222-222: Ordered list item prefix
Expected: 1; Actual: 3; Style: 1/1/1
(MD029, ol-prefix)
🤖 Prompt for AI Agents
In `@docs/testing.md` around lines 222 - 233, The ordered list numbering in the
Gherkin example uses "3." but must restart at "1." to satisfy markdownlint rule
MD029; update the list item label before the code block (the line currently
starting with "3. Test all visible fields") to "1. Test all visible fields" so
the document uses the 1/1/1 style; ensure only the numeric prefix is changed and
the Gherkin block (title/body/field_tags lines) remains unchanged.
f1345a6 to
fc33b49
Compare
Member
Author
|
|
Member
Author
|
Member
Author
|
There was a problem hiding this comment.
Actionable comments posted: 11
🤖 Fix all issues with AI agents
In @.vortex/docs/CLAUDE.md:
- Around line 25-32: The fenced code block showing the docs directory tree in
.vortex/docs/CLAUDE.md is missing a language tag (triggering MD040); update the
opening fence from ``` to ```text so the block becomes a labeled text/code fence
(keep the closing fence ``` unchanged) — locate the directory tree block around
the shown snippet and change the fence for the directory listing accordingly.
In @.vortex/docs/content/deployment/notifications.mdx:
- Around line 53-59: The example for the %timestamp% token is ambiguous
(DD/MM/YYYY); update the %timestamp% entry in the notifications table to use an
unambiguous ISO 8601 example (e.g. 2025-11-15T14:30:45Z) or add a short
parenthetical note after the %timestamp% description explicitly stating the
format used (ISO 8601 / UTC), so consumers know the exact expected timestamp
format.
In @.vortex/docs/content/development/debugging.mdx:
- Around line 122-191: Add a step to ensure the .data directory exists before
saving cookies: in the Ahoy and Docker Compose TabItem code blocks, prepend a
mkdir -p .data command before any curl -c .data/cookies.txt invocation so curl
will not fail when the directory is missing; update the blocks containing the
curl lines (the ones starting "# Step 3: Authenticate and save session cookies"
and referencing "curl -k -c .data/cookies.txt -L \"LOGIN_URL\"") to include this
mkdir step.
In @.vortex/docs/content/development/faqs.mdx:
- Around line 295-300: Update the prose by replacing the shorthand "10min" with
"10 minutes" in the FAQ section titled "Behat tests with `@javascript` tag
sometimes get stuck" so the sentence reads "...sometimes get stuck for about 10
minutes then fail." — locate the paragraph containing the phrase "10min" and
change it to "10 minutes" for clarity and linting compliance.
In @.vortex/docs/content/development/README.mdx:
- Around line 203-207: Add a short explanatory note inside the TabItem with
value "ahoy" next to the raw `docker compose ps` command indicating there is no
`ahoy ps` equivalent (or that Ahoy doesn't expose a container listing command),
so we're using Docker Compose directly; reference the `docker compose ps` and
`ahoy` commands in the comment so readers understand the gap and that this is
intentional or a potential future enhancement.
- Around line 229-230: Update the misleading heading "Increase PHP memory
temporarily" to reflect what the command actually does: change the heading to
something like "Reduce PHP memory usage during install" or "Install Composer
without dev dependencies to lower memory usage" and/or add an alternative note
showing the actual PHP memory increase approach if you intend to show that
(e.g., php -d memory_limit=...). Make the edit where the heading "# Increase PHP
memory temporarily" and the command "ahoy composer install --no-dev
--optimize-autoloader" appear so the text and the command align semantically.
- Line 161: Replace the invalid Drush command usages `drush
cache:rebuild-external` with the standard `drush cache:rebuild` (or `drush cr`)
in the README; locate the two occurrences (the one shown as `ahoy drush
cache:rebuild-external` and the other `docker compose exec cli drush
cache:rebuild-external`) and update them to use `drush cache:rebuild` (or `drush
cr`) so the documented commands match Drush core.
In @.vortex/docs/content/features.mdx:
- Around line 172-178: Update the copy inside the VerticalTabPanel where the
phrase reads "Scripted automation for common tasks configured to run in the same
way in all environments" to "Scripted automations…" to match the tab label
(VerticalTab: "⚙️ Automations"); additionally verify the implementation of the
feature to confirm whether environment variables are the only customization
mechanism—if not, restore or preserve mention of hooks (e.g., "via environment
variables and hooks") instead of removing them, and update the text in
VerticalTabPanel accordingly so the wording accurately reflects the supported
customization mechanisms.
In @.vortex/tests/phpunit/Traits/ProcessTrait.php:
- Around line 42-44: The env array in ProcessTrait.php currently sets
'GITHUB_TOKEN' => getenv('TEST_GITHUB_TOKEN') ?: '' which clears any existing
token; change this so 'GITHUB_TOKEN' uses TEST_GITHUB_TOKEN when present but
otherwise preserves the parent process token (use getenv('TEST_GITHUB_TOKEN') ?:
getenv('GITHUB_TOKEN') ?: '') so the child process doesn't override an existing
GITHUB_TOKEN; update the assignment where 'GITHUB_TOKEN' is defined in the env
array.
In `@docs/ci.md`:
- Around line 8-26: The file has duplicate "## CI provider" headings (the two
"## CI provider" blocks controlled by the markers "#;< CI_PROVIDER_CIRCLECI" and
"#;< CI_PROVIDER_GHA") which triggers linting; fix by either renaming one
heading to include the provider name (e.g., change the CircleCI or GitHub
Actions heading to "## CI provider — CircleCI" or "## CI provider — GitHub
Actions") or suppress the markdownlint duplicate-heading rule for this template
by adding a markdownlint disable comment (e.g., insert an HTML comment to
disable MD024 before the first conditional block and re-enable after) so the
markers "#;< CI_PROVIDER_CIRCLECI" and "#;< CI_PROVIDER_GHA" remain intact.
In `@docs/testing.md`:
- Around line 169-174: Replace the incorrect article in the Gherkin example
string "As a authenticated user" with "As an authenticated user" so the list
reads "As an authenticated user"; search for the exact string "As a
authenticated user" in the Gherkin block and update it to use "an".
Comment on lines
+25
to
+32
| ``` | ||
| docs/ | ||
| ├── content/ # MDX documentation pages | ||
| ├── src/components/ # React components | ||
| ├── tests/unit/ # Jest tests | ||
| ├── sidebars.js # Sidebar configuration | ||
| └── docusaurus.config.js | ||
| ``` |
There was a problem hiding this comment.
Add a language to the fenced code block.
Markdownlint flags this (MD040). Please specify a language for the directory tree block.
Proposed fix
-```
+```text
docs/
├── content/ # MDX documentation pages
├── src/components/ # React components
├── tests/unit/ # Jest tests
├── sidebars.js # Sidebar configuration
└── docusaurus.config.js
-```
+```📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| ``` | |
| docs/ | |
| ├── content/ # MDX documentation pages | |
| ├── src/components/ # React components | |
| ├── tests/unit/ # Jest tests | |
| ├── sidebars.js # Sidebar configuration | |
| └── docusaurus.config.js | |
| ``` |
🧰 Tools
🪛 markdownlint-cli2 (0.20.0)
[warning] 25-25: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🤖 Prompt for AI Agents
In @.vortex/docs/CLAUDE.md around lines 25 - 32, The fenced code block showing
the docs directory tree in .vortex/docs/CLAUDE.md is missing a language tag
(triggering MD040); update the opening fence from ``` to ```text so the block
becomes a labeled text/code fence (keep the closing fence ``` unchanged) —
locate the directory tree block around the shown snippet and change the fence
for the directory listing accordingly.
Comment on lines
+53
to
+59
| | Token | Description | Example | | ||
| |-------|-------------|---------| | ||
| | `%project%` | Project name | `My Project` | | ||
| | `%label%` | Deployment label | `main` or `PR-123` | | ||
| | `%timestamp%` | Current timestamp | `15/11/2025 14:30:45 UTC` | | ||
| | `%environment_url%` | Environment URL | `https://example.com` | | ||
| | `%login_url%` | Login URL | `https://example.com/user/login` | |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Consider ISO 8601 date format for clarity.
The timestamp example 15/11/2025 14:30:45 UTC uses DD/MM/YYYY format, which can be ambiguous internationally (US readers may interpret as MM/DD/YYYY). Consider using ISO 8601 format (2025-11-15T14:30:45Z) for unambiguous documentation, or explicitly note the format.
📝 Suggested alternative
| Token | Description | Example |
|-------|-------------|---------|
| `%project%` | Project name | `My Project` |
| `%label%` | Deployment label | `main` or `PR-123` |
-| `%timestamp%` | Current timestamp | `15/11/2025 14:30:45 UTC` |
+| `%timestamp%` | Current timestamp | `2025-11-15 14:30:45 UTC` |
| `%environment_url%` | Environment URL | `https://example.com` |📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| | Token | Description | Example | | |
| |-------|-------------|---------| | |
| | `%project%` | Project name | `My Project` | | |
| | `%label%` | Deployment label | `main` or `PR-123` | | |
| | `%timestamp%` | Current timestamp | `15/11/2025 14:30:45 UTC` | | |
| | `%environment_url%` | Environment URL | `https://example.com` | | |
| | `%login_url%` | Login URL | `https://example.com/user/login` | | |
| | Token | Description | Example | | |
| |-------|-------------|---------| | |
| | `%project%` | Project name | `My Project` | | |
| | `%label%` | Deployment label | `main` or `PR-123` | | |
| | `%timestamp%` | Current timestamp | `2025-11-15 14:30:45 UTC` | | |
| | `%environment_url%` | Environment URL | `https://example.com` | | |
| | `%login_url%` | Login URL | `https://example.com/user/login` | |
🤖 Prompt for AI Agents
In @.vortex/docs/content/deployment/notifications.mdx around lines 53 - 59, The
example for the %timestamp% token is ambiguous (DD/MM/YYYY); update the
%timestamp% entry in the notifications table to use an unambiguous ISO 8601
example (e.g. 2025-11-15T14:30:45Z) or add a short parenthetical note after the
%timestamp% description explicitly stating the format used (ISO 8601 / UTC), so
consumers know the exact expected timestamp format.
Comment on lines
+122
to
+191
| ## Testing authenticated pages with curl | ||
|
|
||
| Use `curl` with session cookies to simulate manual testing of pages that require | ||
| authentication (admin pages, protected routes) without opening a browser. This | ||
| is for ad-hoc debugging only - automated testing should use Behat or PHPUnit. | ||
|
|
||
| ### When to use | ||
|
|
||
| - Quick ad-hoc debugging of admin page errors (500 errors, permission issues) | ||
| - Investigating issues without spinning up a browser | ||
| - Verifying page content during troubleshooting | ||
| - One-off checks that don't warrant a formal test | ||
|
|
||
| ### Step-by-step process | ||
|
|
||
| <Tabs> | ||
| <TabItem value="ahoy" label="Ahoy" default> | ||
| ```shell | ||
| # Step 1: Get the site URL from project info | ||
| ahoy info | ||
| # Note the URL (e.g., http://your-project.docker.amazee.io) | ||
| # Step 2: Get a one-time login URL | ||
| ahoy login | ||
| # Output example: http://your-project.docker.amazee.io/user/reset/1/1234567890/abc123/login | ||
| # Step 3: Authenticate and save session cookies | ||
| # Replace LOGIN_URL with the full URL from Step 2 | ||
| curl -k -c .data/cookies.txt -L "LOGIN_URL" | ||
| # Step 4: Access any authenticated page using saved cookies | ||
| # Replace SITE_URL with your site URL from Step 1 | ||
| curl -k -b .data/cookies.txt "SITE_URL/admin/content" | ||
| # Step 5: Check for specific errors in page output | ||
| curl -k -b .data/cookies.txt "SITE_URL/admin/content" | grep -iE "(error|exception|warning|notice)" | ||
| ``` | ||
| </TabItem> | ||
| <TabItem value="docker-compose" label="Docker Compose"> | ||
| ```shell | ||
| # Step 1: Get the site URL from project info | ||
| docker compose exec cli ./scripts/vortex/info.sh | ||
| # Note the URL (e.g., http://your-project.docker.amazee.io) | ||
| # Step 2: Get a one-time login URL | ||
| docker compose exec cli drush uli | ||
| # Output example: http://your-project.docker.amazee.io/user/reset/1/1234567890/abc123/login | ||
| # Step 3: Authenticate and save session cookies | ||
| # Replace LOGIN_URL with the full URL from Step 2 | ||
| curl -k -c .data/cookies.txt -L "LOGIN_URL" | ||
| # Step 4: Access any authenticated page using saved cookies | ||
| # Replace SITE_URL with your site URL from Step 1 | ||
| curl -k -b .data/cookies.txt "SITE_URL/admin/content" | ||
| # Step 5: Check for specific errors in page output | ||
| curl -k -b .data/cookies.txt "SITE_URL/admin/content" | grep -iE "(error|exception|warning|notice)" | ||
| ``` | ||
| </TabItem> | ||
| </Tabs> | ||
|
|
||
| ### Curl flags reference | ||
|
|
||
| | Flag | Purpose | | ||
| |------|---------| | ||
| | `-k` | Ignore SSL certificate errors (required for self-signed local certs) | | ||
| | `-c FILE` | Save cookies to FILE after request | | ||
| | `-b FILE` | Send cookies from FILE with request | | ||
| | `-L` | Follow redirects (required for login flow) | | ||
|
|
||
| ### Important notes | ||
|
|
||
| - **Cookie storage**: Always use `.data/` directory - it is gitignored | ||
| - **Session expiry**: Cookies expire after session timeout; regenerate as needed | ||
| - **Login URL format**: `http://SITE/user/reset/UID/TIMESTAMP/HASH/login` | ||
| - **One-time use**: Login URLs from `ahoy login` can only be used once | ||
|
|
There was a problem hiding this comment.
Ensure .data/ exists before saving cookies.
curl -c .data/cookies.txt fails if the directory doesn’t exist. Add a mkdir -p .data step in both tabs to prevent copy/paste errors.
📝 Suggested doc tweak
# Step 3: Authenticate and save session cookies
+ # Ensure cookie directory exists
+ mkdir -p .data
# Replace LOGIN_URL with the full URL from Step 2
curl -k -c .data/cookies.txt -L "LOGIN_URL" # Step 3: Authenticate and save session cookies
+ # Ensure cookie directory exists
+ mkdir -p .data
# Replace LOGIN_URL with the full URL from Step 2
curl -k -c .data/cookies.txt -L "LOGIN_URL"🤖 Prompt for AI Agents
In @.vortex/docs/content/development/debugging.mdx around lines 122 - 191, Add a
step to ensure the .data directory exists before saving cookies: in the Ahoy and
Docker Compose TabItem code blocks, prepend a mkdir -p .data command before any
curl -c .data/cookies.txt invocation so curl will not fail when the directory is
missing; update the blocks containing the curl lines (the ones starting "# Step
3: Authenticate and save session cookies" and referencing "curl -k -c
.data/cookies.txt -L \"LOGIN_URL\"") to include this mkdir step.
Comment on lines
+295
to
+300
| ## Behat tests with `@javascript` tag sometimes get stuck | ||
|
|
||
| Behat tests with `@javascript` tag sometimes get stuck for about 10min then | ||
| fail. The Chrome container randomly gets stuck for an unknown reason. | ||
|
|
||
| Restart the Chrome container: `docker compose restart chrome` |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Consider expanding "10min" for clarity.
The abbreviation "10min" could be written as "10 minutes" for better readability and to satisfy prose linting tools.
✏️ Suggested fix
-Behat tests with `@javascript` tag sometimes get stuck for about 10min then
+Behat tests with `@javascript` tag sometimes get stuck for about 10 minutes then
fail. The Chrome container randomly gets stuck for an unknown reason.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| ## Behat tests with `@javascript` tag sometimes get stuck | |
| Behat tests with `@javascript` tag sometimes get stuck for about 10min then | |
| fail. The Chrome container randomly gets stuck for an unknown reason. | |
| Restart the Chrome container: `docker compose restart chrome` | |
| ## Behat tests with `@javascript` tag sometimes get stuck | |
| Behat tests with `@javascript` tag sometimes get stuck for about 10 minutes then | |
| fail. The Chrome container randomly gets stuck for an unknown reason. | |
| Restart the Chrome container: `docker compose restart chrome` |
🧰 Tools
🪛 LanguageTool
[grammar] ~297-~297: Ensure spelling is correct
Context: ...ript` tag sometimes get stuck for about 10min then fail. The Chrome container randoml...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
🤖 Prompt for AI Agents
In @.vortex/docs/content/development/faqs.mdx around lines 295 - 300, Update the
prose by replacing the shorthand "10min" with "10 minutes" in the FAQ section
titled "Behat tests with `@javascript` tag sometimes get stuck" so the sentence
reads "...sometimes get stuck for about 10 minutes then fail." — locate the
paragraph containing the phrase "10min" and change it to "10 minutes" for
clarity and linting compliance.
| ahoy drush config:set system.performance css.preprocess 1 | ||
| ahoy drush config:set system.performance js.preprocess 1 | ||
| # Clear render cache | ||
| ahoy drush cache:rebuild-external |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Search for cache:rebuild-external command references
echo "=== Searching for cache:rebuild-external in codebase ==="
rg -n "cache:rebuild-external\|cache_rebuild_external" --type=php --type=yamlRepository: drevops/vortex
Length of output: 114
🏁 Script executed:
#!/bin/bash
# Search for Drush command definitions and related patterns
echo "=== Searching for custom Drush commands in services/yml files ==="
find . -name "*.yml" -o -name "*.yaml" | xargs grep -l "drush" 2>/dev/null | head -20Repository: drevops/vortex
Length of output: 1311
🏁 Script executed:
#!/bin/bash
# Look for Drush commands directory and custom commands
echo "=== Searching for Drush command definitions ==="
find . -path "*/drush/Commands" -type d
find . -name "*Command.php" -path "*/drush/*" | head -20Repository: drevops/vortex
Length of output: 105
🏁 Script executed:
#!/bin/bash
# Search for any cache-related commands in the codebase
echo "=== Searching for cache commands and external references ==="
rg -n "cache:" --type=php --type=yaml -A 2 -B 2 | head -50Repository: drevops/vortex
Length of output: 2629
🏁 Script executed:
#!/bin/bash
# Search specifically in the documentation and ahoy file for cache commands
echo "=== Checking ahoy.yml for cache-related commands ==="
cat .ahoy.yml | grep -A 10 -B 2 "cache"Repository: drevops/vortex
Length of output: 554
🏁 Script executed:
#!/bin/bash
# Check what Drush modules might be configured
echo "=== Checking for Drush configuration and module info ==="
find . -name "drush.yml" -o -name "drupal/*/drush" -type d | head -20
if [ -f "./composer.json" ]; then
echo "=== Checking composer.json for drush/cache modules ==="
grep -i "drush\|cache" ./composer.json | head -30
fiRepository: drevops/vortex
Length of output: 382
🏁 Script executed:
#!/bin/bash
# Check Drush command documentation and available commands
echo "=== Checking drush.yml configuration ==="
cat ./drush/drush.ymlRepository: drevops/vortex
Length of output: 516
🏁 Script executed:
#!/bin/bash
# Search for any documentation or comments mentioning external cache
echo "=== Searching for 'external' in documentation ==="
rg -n "external" .vortex/docs --type=mdx --type=markdown -B 2 -A 2Repository: drevops/vortex
Length of output: 152
🏁 Script executed:
#!/bin/bash
# Check if there's any standard Drush cache command documentation
echo "=== Checking for drush cache command usage in the project ==="
rg -n "drush.*cache\|drush.*cr" .vortex/docs --type=mdx --type=markdownRepository: drevops/vortex
Length of output: 164
🏁 Script executed:
#!/bin/bash
# Search for 'external' in the documentation directory
echo "=== Searching for 'external' in documentation ==="
rg -n "external" .vortex/docs --type=markdown -B 2 -A 2Repository: drevops/vortex
Length of output: 107
🏁 Script executed:
#!/bin/bash
# Directly check the specific file mentioned in review
echo "=== Checking the README.mdx file for cache references ==="
grep -n "cache" .vortex/docs/content/development/README.mdxRepository: drevops/vortex
Length of output: 276
🏁 Script executed:
#!/bin/bash
# Check what drush commands are mentioned in the documentation
echo "=== Checking all drush commands mentioned in docs ==="
rg "drush [a-z:_-]+" .vortex/docs/content/development/README.mdx -oRepository: drevops/vortex
Length of output: 347
Remove or correct the non-existent cache:rebuild-external Drush command.
The command drush cache:rebuild-external does not exist in this project or in Drush core. Use the standard drush cache:rebuild command instead (or drush cr as shorthand).
Affected locations
- Line 161:
ahoy drush cache:rebuild-external - Line 172:
docker compose exec cli drush cache:rebuild-external
🤖 Prompt for AI Agents
In @.vortex/docs/content/development/README.mdx at line 161, Replace the invalid
Drush command usages `drush cache:rebuild-external` with the standard `drush
cache:rebuild` (or `drush cr`) in the README; locate the two occurrences (the
one shown as `ahoy drush cache:rebuild-external` and the other `docker compose
exec cli drush cache:rebuild-external`) and update them to use `drush
cache:rebuild` (or `drush cr`) so the documented commands match Drush core.
Comment on lines
+229
to
+230
| # Increase PHP memory temporarily | ||
| ahoy composer install --no-dev --optimize-autoloader |
There was a problem hiding this comment.
Misleading comment: flags reduce memory usage, not increase it.
The comment says "Increase PHP memory temporarily" but --no-dev --optimize-autoloader doesn't increase memory—it reduces memory consumption by excluding dev dependencies. Consider rephrasing to "Reduce memory usage during install" or providing actual PHP memory increase instructions if needed.
📝 Suggested fix
- # Increase PHP memory temporarily
- ahoy composer install --no-dev --optimize-autoloader
+ # Reduce memory footprint by excluding dev dependencies
+ ahoy composer install --no-dev --optimize-autoloader📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| # Increase PHP memory temporarily | |
| ahoy composer install --no-dev --optimize-autoloader | |
| # Reduce memory footprint by excluding dev dependencies | |
| ahoy composer install --no-dev --optimize-autoloader |
🤖 Prompt for AI Agents
In @.vortex/docs/content/development/README.mdx around lines 229 - 230, Update
the misleading heading "Increase PHP memory temporarily" to reflect what the
command actually does: change the heading to something like "Reduce PHP memory
usage during install" or "Install Composer without dev dependencies to lower
memory usage" and/or add an alternative note showing the actual PHP memory
increase approach if you intend to show that (e.g., php -d memory_limit=...).
Make the edit where the heading "# Increase PHP memory temporarily" and the
command "ahoy composer install --no-dev --optimize-autoloader" appear so the
text and the command align semantically.
Comment on lines
+172
to
+178
| <VerticalTab>⚙️ Automations | Useful automations and scripts</VerticalTab> | ||
| <VerticalTabPanel> | ||
|
|
||
| ### Identical workflows across environments | ||
| ### Identical operations across environments | ||
|
|
||
| - Scripted workflows for common tasks configured to run in the same way in all environments | ||
| - Support for workflow customization via hooks | ||
| - Scripted automation for common tasks configured to run in the same way in all environments | ||
| - Support for customization via environment variables |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Consider pluralizing “Scripted automation” for consistency + verify customization mechanism.
The tab label uses “Automations,” so “Scripted automations” may read more consistently. Also, please confirm that environment variables are the sole customization mechanism before removing the “hooks” wording.
💡 Optional wording tweak
- - Scripted automation for common tasks configured to run in the same way in all environments
+ - Scripted automations for common tasks configured to run in the same way in all environments📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| <VerticalTab>⚙️ Automations | Useful automations and scripts</VerticalTab> | |
| <VerticalTabPanel> | |
| ### Identical workflows across environments | |
| ### Identical operations across environments | |
| - Scripted workflows for common tasks configured to run in the same way in all environments | |
| - Support for workflow customization via hooks | |
| - Scripted automation for common tasks configured to run in the same way in all environments | |
| - Support for customization via environment variables | |
| <VerticalTab>⚙️ Automations | Useful automations and scripts</VerticalTab> | |
| <VerticalTabPanel> | |
| ### Identical operations across environments | |
| - Scripted automations for common tasks configured to run in the same way in all environments | |
| - Support for customization via environment variables |
🤖 Prompt for AI Agents
In @.vortex/docs/content/features.mdx around lines 172 - 178, Update the copy
inside the VerticalTabPanel where the phrase reads "Scripted automation for
common tasks configured to run in the same way in all environments" to "Scripted
automations…" to match the tab label (VerticalTab: "⚙️ Automations");
additionally verify the implementation of the feature to confirm whether
environment variables are the only customization mechanism—if not, restore or
preserve mention of hooks (e.g., "via environment variables and hooks") instead
of removing them, and update the text in VerticalTabPanel accordingly so the
wording accurately reflects the supported customization mechanisms.
Comment on lines
+42
to
44
| // GitHub token for API calls to avoid rate limiting. | ||
| 'GITHUB_TOKEN' => getenv('TEST_GITHUB_TOKEN') ?: '', | ||
| ]; |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Find and examine the ProcessTrait.php file
find . -name "ProcessTrait.php" -type fRepository: drevops/vortex
Length of output: 105
🌐 Web query:
Symfony Process class environment variable parameter behavior merge override
💡 Result:
In Symfony’s Process component, the environment you pass is merged with the parent (system) environment, and your provided keys take precedence (override) for that child process. Processes inherit the system env by default. You can remove an inherited variable by setting its value to false in the env array. [1]
use Symfony\Component\Process\Process;
$process = new Process(['mycmd'], null, [
'FOO' => 'child-value', // overrides/injects for the subprocess
'BAR' => false, // removes BAR even if it exists in the parent env
]);Notes:
Process::run()/start()/mustRun()also accept an$envarray that is applied for that execution, using the same rules. [1]- With
setEnv(), values should be strings; arrays are ignored; andfalse/nullmeans “remove when env vars are otherwise inherited”. [2] - The older API to disable inheriting env vars (
inheritEnvironmentVariables()) was deprecated/removed because environment variables are always inherited (you only “subtract” specific ones viafalse). [3]
Sources: Symfony Process docs on passing env and using false to unset [1]; Process setEnv() behavior (false/null remove; arrays ignored) [2]; upgrade note that env vars are always inherited [3].
[1] https://symfony.com/doc/current/components/process.html
[2] https://docs.w3cub.com/symfony~4.1/symfony/component/process/process
[3] https://sources.debian.org/src/symfony/3.4.22%2Bdfsg-2%2Bdeb10u1/UPGRADE-4.0.md
🏁 Script executed:
cat -n ./.vortex/tests/phpunit/Traits/ProcessTrait.phpRepository: drevops/vortex
Length of output: 3698
Preserve existing GitHub token when test token is unavailable.
Setting GITHUB_TOKEN to an empty string overrides any parent environment token in the child process. When TEST_GITHUB_TOKEN is unset, fall back to the existing GITHUB_TOKEN instead of clearing it.
Suggested fix
- 'GITHUB_TOKEN' => getenv('TEST_GITHUB_TOKEN') ?: '',
+ 'GITHUB_TOKEN' => getenv('TEST_GITHUB_TOKEN') ?: getenv('GITHUB_TOKEN') ?: '',📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| // GitHub token for API calls to avoid rate limiting. | |
| 'GITHUB_TOKEN' => getenv('TEST_GITHUB_TOKEN') ?: '', | |
| ]; | |
| // GitHub token for API calls to avoid rate limiting. | |
| 'GITHUB_TOKEN' => getenv('TEST_GITHUB_TOKEN') ?: getenv('GITHUB_TOKEN') ?: '', | |
| ]; |
🤖 Prompt for AI Agents
In @.vortex/tests/phpunit/Traits/ProcessTrait.php around lines 42 - 44, The env
array in ProcessTrait.php currently sets 'GITHUB_TOKEN' =>
getenv('TEST_GITHUB_TOKEN') ?: '' which clears any existing token; change this
so 'GITHUB_TOKEN' uses TEST_GITHUB_TOKEN when present but otherwise preserves
the parent process token (use getenv('TEST_GITHUB_TOKEN') ?:
getenv('GITHUB_TOKEN') ?: '') so the child process doesn't override an existing
GITHUB_TOKEN; update the assignment where 'GITHUB_TOKEN' is defined in the env
array.
Comment on lines
+8
to
+26
| ## CI provider | ||
|
|
||
| This project uses [Circle CI](https://circleci.com/) as a CI server: it imports | ||
| production backups into fully built codebase and runs code linting and tests. | ||
| When tests pass, a deployment process is triggered for nominated branches | ||
| (usually, `main` and `develop`). | ||
| This project uses [CircleCI](https://circleci.com/). | ||
|
|
||
| Refer to https://www.vortextemplate.com/docs/continuous-integration for more | ||
| information. | ||
|
|
||
| ### Skipping CI build | ||
|
|
||
| Add `[skip ci]` to the commit subject to skip CI build. Useful for documentation | ||
| changes. | ||
|
|
||
| ### SSH | ||
|
|
||
| Circle CI supports shell access to the build for 120 minutes after the build is | ||
| finished when the build is started with SSH support. Use "Rerun job with SSH" | ||
| button in Circle CI UI to start build with SSH support. | ||
| See [CircleCI documentation](https://www.vortextemplate.com/docs/continuous-integration/circleci) | ||
| for setup and configuration details. | ||
|
|
||
| [//]: # (#;> CI_PROVIDER_CIRCLECI) | ||
|
|
||
| [//]: # (#;< CI_PROVIDER_GHA) | ||
|
|
||
| ## GitHub Actions | ||
|
|
||
| This project uses [GitHub Actions](https://github.com/features/actions) as a | ||
| CI server: it imports production backups into fully built codebase and runs | ||
| code linting and tests. When tests pass, a deployment process is triggered for | ||
| nominated branches (usually, `main` and `develop`). | ||
| ## CI provider | ||
|
|
||
| Refer to https://www.vortextemplate.com/docs/continuous-integration for more | ||
| information. | ||
| This project uses [GitHub Actions](https://github.com/features/actions). | ||
|
|
||
| ### Skipping CI build | ||
| See [GitHub Actions documentation](https://www.vortextemplate.com/docs/continuous-integration/github-actions) | ||
| for setup and configuration details. | ||
|
|
||
| Add `[skip ci]` to the commit subject to skip CI build. Useful for documentation | ||
| changes. | ||
|
|
||
| ### SSH | ||
|
|
||
| GitHub Actions does not supports shell access to the build, but there is an | ||
| action provided withing the `build` job that allows you to run a build with SSH | ||
| support. | ||
| [//]: # (#;> CI_PROVIDER_GHA) |
There was a problem hiding this comment.
Duplicate heading "## CI provider" may cause issues in non-processed views.
The static analysis tool flagged duplicate ## CI provider headings on lines 8 and 19. While these sections are mutually exclusive (controlled by #;< CI_PROVIDER_CIRCLECI and #;< CI_PROVIDER_GHA markers), the duplicate headings could cause:
- Markdown linting failures in CI
- Confusion when viewing the raw file
Consider differentiating the headings or suppressing the lint rule if this is intentional template behavior.
💡 Possible fix options
Option 1: Differentiate headings
[//]: # (#;< CI_PROVIDER_CIRCLECI)
-## CI provider
+## CI provider (CircleCI)
This project uses [CircleCI](https://circleci.com/). [//]: # (#;< CI_PROVIDER_GHA)
-## CI provider
+## CI provider (GitHub Actions)
This project uses [GitHub Actions](https://github.com/features/actions).Option 2: Add markdownlint disable comment
+<!-- markdownlint-disable MD024 -->
+
[//]: # (#;< CI_PROVIDER_CIRCLECI)📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| ## CI provider | |
| This project uses [Circle CI](https://circleci.com/) as a CI server: it imports | |
| production backups into fully built codebase and runs code linting and tests. | |
| When tests pass, a deployment process is triggered for nominated branches | |
| (usually, `main` and `develop`). | |
| This project uses [CircleCI](https://circleci.com/). | |
| Refer to https://www.vortextemplate.com/docs/continuous-integration for more | |
| information. | |
| ### Skipping CI build | |
| Add `[skip ci]` to the commit subject to skip CI build. Useful for documentation | |
| changes. | |
| ### SSH | |
| Circle CI supports shell access to the build for 120 minutes after the build is | |
| finished when the build is started with SSH support. Use "Rerun job with SSH" | |
| button in Circle CI UI to start build with SSH support. | |
| See [CircleCI documentation](https://www.vortextemplate.com/docs/continuous-integration/circleci) | |
| for setup and configuration details. | |
| [//]: # (#;> CI_PROVIDER_CIRCLECI) | |
| [//]: # (#;< CI_PROVIDER_GHA) | |
| ## GitHub Actions | |
| This project uses [GitHub Actions](https://github.com/features/actions) as a | |
| CI server: it imports production backups into fully built codebase and runs | |
| code linting and tests. When tests pass, a deployment process is triggered for | |
| nominated branches (usually, `main` and `develop`). | |
| ## CI provider | |
| Refer to https://www.vortextemplate.com/docs/continuous-integration for more | |
| information. | |
| This project uses [GitHub Actions](https://github.com/features/actions). | |
| ### Skipping CI build | |
| See [GitHub Actions documentation](https://www.vortextemplate.com/docs/continuous-integration/github-actions) | |
| for setup and configuration details. | |
| Add `[skip ci]` to the commit subject to skip CI build. Useful for documentation | |
| changes. | |
| ### SSH | |
| GitHub Actions does not supports shell access to the build, but there is an | |
| action provided withing the `build` job that allows you to run a build with SSH | |
| support. | |
| [//]: # (#;> CI_PROVIDER_GHA) | |
| ## CI provider (CircleCI) | |
| This project uses [CircleCI](https://circleci.com/). | |
| See [CircleCI documentation](https://www.vortextemplate.com/docs/continuous-integration/circleci) | |
| for setup and configuration details. | |
| [//]: # (#;> CI_PROVIDER_CIRCLECI) | |
| [//]: # (#;< CI_PROVIDER_GHA) | |
| ## CI provider (GitHub Actions) | |
| This project uses [GitHub Actions](https://github.com/features/actions). | |
| See [GitHub Actions documentation](https://www.vortextemplate.com/docs/continuous-integration/github-actions) | |
| for setup and configuration details. | |
| [//]: # (#;> CI_PROVIDER_GHA) |
🧰 Tools
🪛 markdownlint-cli2 (0.20.0)
[warning] 19-19: Multiple headings with the same content
(MD024, no-duplicate-heading)
🤖 Prompt for AI Agents
In `@docs/ci.md` around lines 8 - 26, The file has duplicate "## CI provider"
headings (the two "## CI provider" blocks controlled by the markers "#;<
CI_PROVIDER_CIRCLECI" and "#;< CI_PROVIDER_GHA") which triggers linting; fix by
either renaming one heading to include the provider name (e.g., change the
CircleCI or GitHub Actions heading to "## CI provider — CircleCI" or "## CI
provider — GitHub Actions") or suppress the markdownlint duplicate-heading rule
for this template by adding a markdownlint disable comment (e.g., insert an HTML
comment to disable MD024 before the first conditional block and re-enable after)
so the markers "#;< CI_PROVIDER_CIRCLECI" and "#;< CI_PROVIDER_GHA" remain
intact.
Comment on lines
+169
to
+174
| ```gherkin | ||
| As a site visitor # Anonymous users | ||
| As a site administrator # Admin users | ||
| As a content editor # Content management users | ||
| As a authenticated user # Logged-in users | ||
| ``` |
There was a problem hiding this comment.
Fix article usage in the user-type example.
Line 173 should read “an authenticated user.”
✏️ Suggested fix
-As a authenticated user # Logged-in users
+As an authenticated user # Logged-in users🤖 Prompt for AI Agents
In `@docs/testing.md` around lines 169 - 174, Replace the incorrect article in the
Gherkin example string "As a authenticated user" with "As an authenticated user"
so the list reads "As an authenticated user"; search for the exact string "As a
authenticated user" in the Gherkin block and update it to use "an".
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary by CodeRabbit
Documentation
New Features
Chores