anchor.diff:  </pre>
   
   The application will then be deployed to Cloud Foundry, and the buildpack will be cloned from the repository and applied to the application (provided that the `detect` script returns `0`).
  +
  +## <a id='disabling-custom-buildpacks'></a>Disabling Custom Buildpacks ##
  +
  +Operators can choose to disable custom buildpacks. For more information, see [Disabling Custom Buildpacks](../adminguide/buildpacks.html#disabling-custom-buildpacks). 
  +
  + <p class="note"><strong>Note</strong>: A common development practice for custom buildpacks is to fork existing buildpacks and sync subsequent patches from upstream. To merge upstream patches to your custom buildpack, use the approach that Github recommends for <a href="https://help.github.com/articles/syncing-a-fork">syncing a fork</a>.</p>
  
positive.code: 
  ### <a id='compile-script'></a>bin/compile ###
  
  The `compile` script builds the droplet that will be run by the DEA and will therefore contain all the components necessary to run the application.
  
  The script is run with two arguments, the build directory for the application and the cache directory, which is a location the buildpack can use to store assets during the build process.
  
  
negative.code: end
  
  ~~~
  ### <a id='release-script'></a>bin/release ###
  
  The `release` script provides feedback metadata back to Cloud Foundry indicating how the application should be executed. The script is run with one argument, the build location of the application. The script must generate a YAML file in the following format:
  