Devdocs: Why track keep replacing gitignore files?

Created on 14 Feb 2018  路  3Comments  路  Source: magento/devdocs

Based on the process outlined here: https://github.com/magento/devdocs/blob/develop/guides/v2.2/config-guide/deployment/pipeline/build-system.md

It seems this requires constantly editing the gitignore file on the build system and recommitting it every time you do a build since it will revert to the development version.

Since you are already promoting a seperation between configuration data and code, gitignore files are merely another form of configuration.

Keep multiple gitignore files in your repository. For a Dev/Build/Production system you could decide on using 2 or 3 files:
.gitignore.dev
.gitignore.build
.gitignore.production

These files should be copied to .git/info/exclude. Unless these files change in the future, each system will now happily ignore the files they are not supposed to be interested in, without the need to ever "edit" a file frequently just to perform a release.

2.3.x Help Wanted

Most helpful comment

Also, the fact that you should EXCLUDE some files on dev and INCLUDE them on build/prod feels like a mis-use of VCS. Surely the process should be to build a compressed artifact on the build server that can then be deployed to prod, rather than introducing generated code (adding a huge amount of unnecessary bloat) into the repository.

All 3 comments

Also, the fact that you should EXCLUDE some files on dev and INCLUDE them on build/prod feels like a mis-use of VCS. Surely the process should be to build a compressed artifact on the build server that can then be deployed to prod, rather than introducing generated code (adding a huge amount of unnecessary bloat) into the repository.

@akaplya Any suggestions here for best practices?

Thank you聽for聽your feedback @gamort! It doesn't seem like your issue is related to Magento DevDocs documentation, but is instead related to engineering/architecture processes. We have pinged an internal resource, in case this warrants being addressed on that side.

Thanks for taking the time to create a GitHub issue for docs improvement! If you feel this IS something we can help address, please feel free to open a new issue.

Was this page helpful?
0 / 5 - 0 ratings