electronjs.org-new/.gitignore

node_modules
.docusaurus
.DS_Store
.env
.vscode/settings.json
.tmp/
build/
content/
i18n/
!i18n/en/
!i18n/README.md
docs/v**
chore: npx docusaurus 2021-03-23 01:04:52 +03:00			`node_modules`
chore: update .gitignore 2021-03-23 20:19:42 +03:00			`.docusaurus`
			`.DS_Store`
build: update content when upstream changes This commit adds support to respond to `repository_dispatch` events coming from `electron/electron-website-updater` that contain the SHA of the new commit in `electron/electron` to pin to in `package.json`. More information about the architecture can be found in #19. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Fix #19 Close #23 2021-05-14 07:08:47 +03:00			`.env`
feat: preserve sidebar order with new content This change makes sure that `sidebars.js` is not generated from scratch each time that `prebuild` is called: - New content is added at the end of the corresponding category or in a new one if it does not exist. - If no new content is found, `sidebars.js` is left unmodified. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Fix #8 2021-04-23 21:16:51 +03:00			`.vscode/settings.json`
feat: versioned docs The way versioned documents are supported on the site differs a bit from Docusaurus' documentation: - Each doc change to a branch is build and publish separately. - The links to the versions are `_blank` to bypass `react-router` even though the content is in the same server. The reason is that because it is built at different steps it is not "found". This is achieve thanks to `electron-website-updater` sending a `repository_dispatch` event with 2 different types of actions for each `push` event that happens in `electron/electron` that contains doc changes. The 2 types of events are: * `doc_changes_branches`: Updates to documentation branches (does not matter if they are the latest or not). * `doc_changes`: Updates to the latest stable branch. The tasks to perform are almost identical and are split in two different GitHub actions for each event: 1. Download the markdown for the SHA, check if there are new version branches and update `versions-info.json`, update the SHA, and publish those changes to Git. This is done in `update-docs-XXX.yml` when we receive the event. 2. Build the content for that branch and publish in the right place. This is done in `push-XXX.yml` when there is a push to `main` or a `vXX` branch. The deployment is done to the storage service. The difference is that a branch will only push `assets` and `docs` while `main` will publish everything. Additionally, Crowdin gets updated every time there is a change in `main` to make sure the latest content is always uploaded. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Fix #118 2021-10-14 06:16:09 +03:00			`.tmp/`
chore: fixes for static publishing Fix broken links and ignore static output folder (`build/`) 2021-04-26 22:26:25 +03:00			`build/`
feat: Crowdin integration Integrates with Crowdin to enable i18n of the site. This PR changes the source of truth for Crowdin and moves it to this repository instead of relying on `electron/i18n`. Additionally it uses Crowdin's CLI to do the upload/download of assets making it more reliable. The website is built on locale at a time via `yarn i18n:build`. Otherwise the process crashed with an out of memory error. The regular `yarn build` command still compiles the `en` locale. Because we cannot get notifications when there are new translations avaiable, there is a GitHub workflow (`update-i18n-deploy.yml`) that downloads the content every few minutes, builds, and deploy. To speed up this process, the previous generated assets are download. In local tests this reduces the build times from 250s to 40s so the whole process should take about 5 minutes. The previous generated content is stored in Azure Storage. Because this is a static website it makes more sense than having a dyno and will make it easier to: - deploy multiple locales at the same time if we still need to speed up the process - have versioned docs because we just need to "take a snapshot" and publish to a different folder The current live site is still not using this storage but will soon-ish. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Fix #64 2021-10-02 00:47:41 +03:00			`content/`
			`i18n/`
feat: versioned docs The way versioned documents are supported on the site differs a bit from Docusaurus' documentation: - Each doc change to a branch is build and publish separately. - The links to the versions are `_blank` to bypass `react-router` even though the content is in the same server. The reason is that because it is built at different steps it is not "found". This is achieve thanks to `electron-website-updater` sending a `repository_dispatch` event with 2 different types of actions for each `push` event that happens in `electron/electron` that contains doc changes. The 2 types of events are: * `doc_changes_branches`: Updates to documentation branches (does not matter if they are the latest or not). * `doc_changes`: Updates to the latest stable branch. The tasks to perform are almost identical and are split in two different GitHub actions for each event: 1. Download the markdown for the SHA, check if there are new version branches and update `versions-info.json`, update the SHA, and publish those changes to Git. This is done in `update-docs-XXX.yml` when we receive the event. 2. Build the content for that branch and publish in the right place. This is done in `push-XXX.yml` when there is a push to `main` or a `vXX` branch. The deployment is done to the storage service. The difference is that a branch will only push `assets` and `docs` while `main` will publish everything. Additionally, Crowdin gets updated every time there is a change in `main` to make sure the latest content is always uploaded. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Fix #118 2021-10-14 06:16:09 +03:00			`!i18n/en/`
docs: update i18n/README.md (#531) 2024-03-05 00:06:01 +03:00			`!i18n/README.md`
feat: add apps showcase section (#249) 2022-09-07 02:58:32 +03:00			`docs/v**`