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.
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.
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.