Recently the cflinuxfs3 builder image was updated. This update resulted in the removal of the archiveexpanding buildpack:

➜ pack inspect-builder cloudfoundry/cnb:0.0.68-cflinuxfs3

Detection Order:
  Group #1:
    org.cloudfoundry.archiveexpanding             (optional)
    org.cloudfoundry.openjdk
    org.cloudfoundry.buildsystem                  (optional)
    org.cloudfoundry.jvmapplication
    org.cloudfoundry.tomcat                       (optional)
    org.cloudfoundry.springboot                   (optional)
    org.cloudfoundry.distzip                      (optional)
    org.cloudfoundry.procfile                     (optional)
    org.cloudfoundry.azureapplicationinsights     (optional)
    org.cloudfoundry.debug                        (optional)
    org.cloudfoundry.googlestackdriver            (optional)
    org.cloudfoundry.jdbc                         (optional)
    org.cloudfoundry.jmx                          (optional)
    org.cloudfoundry.springautoreconfiguration    (optional)

➜ pack inspect-builder cloudfoundry/cnb:cflinuxfs3

Detection Order:
  Group #1:
    org.cloudfoundry.openjdk
    org.cloudfoundry.buildsystem                  (optional)
    org.cloudfoundry.jvmapplication
    org.cloudfoundry.tomcat                       (optional)
    org.cloudfoundry.springboot                   (optional)
    org.cloudfoundry.distzip                      (optional)
    org.cloudfoundry.procfile                     (optional)
    org.cloudfoundry.azureapplicationinsights     (optional)
    org.cloudfoundry.debug                        (optional)
    org.cloudfoundry.googlestackdriver            (optional)
    org.cloudfoundry.jdbc                         (optional)
    org.cloudfoundry.jmx                          (optional)
    org.cloudfoundry.springautoreconfiguration    (optional)

A consequence of removing archiveexpanding is that it changes the semantics of pack build. With archiveexpanding in the detection group, it is possible to run pack build some-project from within the directory that contains the jar/war and successfully generate an image which will run some-project.

Now that it's removed, that command will fail with the following (truncated) output:

[detector] ERROR: No buildpack groups passed detection.
[detector] ERROR: Please check that you are running against the correct path.
[detector] ERROR: failed to detect: no buildpacks participating
ERROR: failed with status code: 6

The resolution is to change the pack invocation to pack build -p path-to-warfile some-project.

I have no strong opinion about the value provided by the archiveexpanding buildpack. However the behavior of the pack build command changing with an update to the cflinuxfs3 builder (and mitigation steps) was a surprise and a proved to be a bit of a challenge to track down.

I have two questions:

• Was it intentional to make specifying --path required?
• How are builder changes (and their mitigation steps) which can impact build / detect behavior communicated?

Pivotal provides the Gitbot service to synchronize issues and pull requests made against public GitHub repos with Pivotal Tracker projects.

If you do not want to use Pivotal Tracker to manage this GitHub repo, you do not need to take any action.

If you are a Pivotal employee, you can configure Gitbot to sync your GitHub repo to your Pivotal Tracker project with a pull request.

Steps:

• Add the Toolsmiths-Bots team to have admin access to your repo
• Add the cf-gitbot ([email protected]) user to have owner access to your Pivotal Tracker project
• Create new branch in this repo: cfgitbot-config (an ask+cf@ ticket is the fastest way to get write access if you get a 404)
• Add your new repo and or project to config-production.yml file
• Submit a PR, which will get auto-merged if you've done it right. Detailed steps here

If you are not a pivotal employee, you can request that [email protected] set up the integration for you.

You might also be interested in configuring GitHub's Service Hook for Tracker on your repo so you can link your commits to Tracker stories. You can do this yourself by following the directions at:

https://www.pivotaltracker.com/blog/guide-githubs-service-hook-tracker/

If there are any questions, please reach out to [email protected].