- add eslint & eslint-plugin-astro
- when using dependabot, we have to run e2e tests (e.g. playwrite) to make sure the dependabot updates don't break the sites
- run tests before commiting
- write blogpost about how to deploy to cloudflare pages with github actions
- auto-merging Pull-Request from dependabot (make sense when having good tests)
- write blogpost about how to autonoumously test a blog with playwrite with ariaSnapshots
- Disable a direct push to GitHub main branch [ ] - https://dev.to/pixiebrix/disable-a-direct-push-to-github-main-branch-8c2
- write a crawler which will crawl the site and create snapshots of every page with
await page.locator('body').ariaSnapshot()
in order to use them for playwrite tests before deploying the site. - github actions
- split test and deploy into separate workflow files
-
Deploy git strategy
-
when created a pull-request or pushed into it or when pushed to main
pull_request: # We are using the different types to ensure that the pipeline does not run unnecessarily on every push. # This makes sense when we are using Cloudflare-Pages which are limited to 500 builds per month. types: # https://frontside.com/blog/2020-05-26-github-actions-pull_request/ # https://github.com/orgs/community/discussions/24567#discussioncomment-8068482 # https://docs.github.com/en/webhooks/webhook-events-and-payloads?actionType=assigned#pull_request # This type triggers the workflow when a new pull request is created. It ensures that the # pipeline runs as soon as the pull request is initiated. - opened # This type triggers the workflow when commits are added, removed, or updated in an open # pull request. For instance, if you push new changes to the branch linked to the pull # request, the workflow will re-run. - synchronize # This type triggers the workflow when a previously closed pull request is reopened. It helps # ensure that the pipeline runs again if the pull request is revisited after being closed. - reopened
-
-
When we want that dependabot should only runs for example only in test job
deploy: # The github.actor is a context variable in GitHub Actions that represents the username of # the user who triggered the workflow run. Here are some key points about github.actor if: ${{ github.actor != 'dependabot[bot]' }}
-
What to do on cloudflare
-
dash.cloudflare.com > Workers & Pages > honey-glass > View Details > Build > Settings
- in
Branch Control
disableEnable automatic production branch deployments
- This message is then displayed (which is fine):
- Automatic production branch deployments are disabled for your git integration. Re-enable automatic deployments to resume builds triggered by git pushes.
- in
Preview branch
enableNone (Disable automatic branch deployments)
- in
Build Configurations
emptyBuild command
andOutput directory
- in
Git Repository
will redirect to Github. Suspend the Github-Plugin Cloudflare integration This makes sense when we are using Cloudflare-Pages which are limited to 500 builds per month. https://github.com/settings/installations (seeCloudflare Pages
) - dash.cloudflare.com/profile/api-tokens
- create token > create custom token
- Account | Cloudflare Pages | Edit
- User | User Details | Read
- create token > create custom token
- Copy
Account ID
- dash.cloudflare.com > honey.glass
- Scroll down to
Account ID
- Scroll down to
- dash.cloudflare.com > honey.glass
- You can build up to 500 times per month on the Free plan
- What counts a build in clouflare pages?
- in our solution only when creatng a PR or pushing to main triggers a build
- How to mesure the build Limit Count?
- in
-
What to do on Gitub
- https://github.com/{accountName}/{repositoryName}
- Settings > Secrets & Variables > Actions > New repository secret
- Name:
CLOUDFLARE_ACCOUNT_ID
andCLOUDFLARE_API_TOKEN
- Name:
- Settings > Secrets & Variables > Actions > New repository secret
- https://github.com/{accountName}/{repositoryName}
-
Tutorial which was useful
see src/drafts/
Runs the end-to-end tests:
pnpm exec playwright test
Starts the interactive UI mode:
pnpm exec playwright test --ui
Runs the tests only on Desktop Chrome:
pnpm exec playwright test --project=chromium
Runs the tests in a specific file:
pnpm exec playwright test example
Runs the tests in debug mode:
pnpm exec playwright test --debug
Auto generate tests with Codegen:
pnpm exec playwright codegen
βββ public/
βββ src/
βΒ Β βββ components/
βΒ Β βββ content/
βΒ Β βββ data/
βΒ Β βββ icons/
βΒ Β βββ layouts/
βΒ Β βββ pages/
βΒ Β βββ plugins/
βΒ Β βββ styles/
βΒ Β βββ utils/
βββ astro.config.mjs
βββ package.json
βββ README.md
βββ tailwind.config.cjs
βββ tsconfig.json
Astro looks for .astro
or .md
files in the src/pages/
directory. Each page is exposed as a route based on its file name.
There's nothing special about src/components/
, but that's where we like to put any Astro (.astro
) components.
The src/content/
directory contains "collections" of related Markdown and MDX documents. Use getCollection()
to retrieve posts from src/content/blog/
, and type-check your frontmatter using an optional schema. See Astro's Content Collections docs to learn more.
Any static assets, like images, can be placed in the public/
directory.
All commands are run from the root of the project, from a terminal:
Command | Action |
---|---|
npm install |
Installs dependencies |
npm run dev |
Starts local dev server at localhost:4321 |
npm run build |
Build your production site to ./dist/ |
npm run preview |
Preview your build locally, before deploying |
npm run astro ... |
Run CLI commands like astro add , astro check |
npm run astro -- --help |
Get help using the Astro CLI |
Licensed under the GPL-3.0 license.