Skip to content
This repository has been archived by the owner on Nov 19, 2024. It is now read-only.

Move downloadables from the repository #6807

Closed
dshevtsov opened this issue Mar 6, 2020 · 5 comments · Fixed by #6828
Closed

Move downloadables from the repository #6807

dshevtsov opened this issue Mar 6, 2020 · 5 comments · Fixed by #6828
Assignees
Labels
Site Improvements Updates to tools, processes, and site architecture that improve reader and contributor experience Tracking Created an internal Jira ticket to track work

Comments

@dshevtsov
Copy link
Collaborator

New feature request

Description

The repository contains large binary files linked in topics as downloadables such as images of proprietary formats and archives, that sufficiently enlarges the repository in size. It would be great to have them as just links like https://devdocs.magento.com/downloads to avoid tracking the huge files in git and adding them to each build.

Expected result

  1. All downloadables are removed from the repository.
  2. All downloadables are still available by the appropriately updates links.

Benefits

This will help to avoid unneeded inflation of the repository.
Local development will take far less space on disk.

Possible solutions

Move the downloadables to https://devdocs.magento.com/downloads or other Magento-supported DNS and maintain them separately.

Additional information

@dshevtsov dshevtsov added the Site Improvements Updates to tools, processes, and site architecture that improve reader and contributor experience label Mar 6, 2020
@jeff-matthews
Copy link
Contributor

@dshevtsov, I found several .pdf, .psd, and .zip files in the project that should be moved. Can you think of any other file types I should search for?

@dshevtsov
Copy link
Collaborator Author

.ai, .sketch
@dobooth maybe you can add more.

@jeff-matthews
Copy link
Contributor

jeff-matthews commented Mar 9, 2020

I propose moving the binaries to a new object in our S3 bucket called downloads/. We do something similar on the docs.magento.com site for storing PDFs.

I can create the new object on S3 and update links in a new devdocs branch to show how this would work.

We would also need to update the devdocs production Jenkins pipeline to exclude the new object so it doesn't get deleted on subsequent deployments.

I can also create a branch for the change in the infra repo.

The only thing left to consider is how we plan to manage and backup these binary files.

  • What if we lose data on S3 and need to redeploy the binaries for some reason?
  • What if a team member needs to add a new binary file?
  • Where should we store these binaries?
  • Should we create a pipeline to manage these interactions?

@jeff-matthews
Copy link
Contributor

See DOC-120

@jeff-matthews jeff-matthews added the Tracking Created an internal Jira ticket to track work label Mar 10, 2020
@dshevtsov
Copy link
Collaborator Author

dshevtsov commented Mar 10, 2020

The discussion about internal implementation will be moved to internal channels.
Any important highlights about affected content or changes in contribution workflows will be shared here.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Site Improvements Updates to tools, processes, and site architecture that improve reader and contributor experience Tracking Created an internal Jira ticket to track work
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants