Buildpack Versioning

[Rasheed Abdul-Aziz]

Non-JVM buildpacks do not have an effective way of identifying the buildpack version in use.

We're aware of this and are currently working on implementing version imprints. If you're interested, you can see the tracker epic here.

The buildpack team are always open to feedback. You can:

• Open issues on any of the buidlpack issue trackers, e.g. for go: https://github.com/cloudfoundry/go-buildpack/issues
  
• Reply to this thread

Kind regards,

  Rasheed Abdul-Aziz and the Buildpack Team.

[Noburou Taniguchi]

Hi,

Our team has happened to this issue [1] today.

[1] https://github.com/cloudfoundry/ruby-buildpack/issues/15

Is it related to the action you mentioned in this thread?

2014年7月16日水曜日 23時44分59秒 UTC+9 Rasheed Abdul-Aziz:

[Rasheed Abdul-Aziz]

It is. Sorry for the pain felt. We'll have the tags reinstated as soon as we can.

[Noburou Taniguchi]

Thanks for your quick response.

2014年7月18日金曜日 20時59分13秒 UTC+9 Rasheed Abdul-Aziz:

[Guillaume Berche]

Hi Rasheed,

Thanks for shaing the pointer on this epic. Reading associated stories, it seems mainly linked to automatically generaed github releases.

Would that also include displaying git commit id and last change logs for custom buildpacks repos as discussed into [1] ?

Is there an update avail on buildpack team strategy related to sharing buildpack infrastructure discussed in [1] or a design document ? I did not find related topic in tracker (squid cache, integration testing java-buildpack-system-test vs anvil)

Thanks in advance,

Guillaume.

[1] https://groups.google.com/a/cloudfoundry.org/d/msg/vcap-dev/A84xVoi8MmE/AuQt3nF3ImcJ

[rabdu...@pivotal.io]

Hi Guillaume.

 

Does this answer your question regarding what's included and not? If not let me know.

Buildpack infrastructure is shared, and it differes greatly between JVM and non-jvm buildpacks.

The non-JVM buidlpack' infrastructure is prone to flux, so much that there are large API changes in the space of a single commit. Nonetheless, it's open and accessible. We currently have:

• Machete - a testing framework to integration test a buildpack and it's functionality.
• The Machete firewall test - that demonstrates simple use of Machete and of an ancilliary script for establishing an on-premises emulation in Bosh-Lite.
• Compile Extensions - A simple extension for caching dependencies
• Buildpack Packager - A simple extension to provide bin/package - a way to roll up dependencies in a pre-cached buildpack.

Let me quickly point out whats about to change.

Machete - We hope to make Machete test from within the Droplet environment. Currently an integration test through Bosh-Lite makes for very slow tests. We're not fans. We will make machete run tests in a VM with the same environment as the DEA, starting up warden containers which share the root filesystem with the buildpacks and fixture apps. This entirely mitigates the cost of copying buildpacks and apps throughout the entire cf system during a test.

The firewall test and script will be replaced with scripting to manage security groups instead.

The Compile Extensions will be modified to use a curl stand in app (written and tested in ruby) and path injection to hide the real 'curl'. This will allow us to use a mature application language like ruby to improve reporting and logging.

The Buildpack Packager is going back to Ruby. We need to manage metadata for dependencies and Bash is not really a suitable language.

Theres more on the horizon. Keep an eye on our tracker: Buildpacks (start with epics). 

[Guillaume Berche]

Thanks for the update, see responses inline below

The delta of changes with pointers to stories containing related github commits looks great.

It would be great to enable machete to run tests against a remote CF instance, similarly as what heroku-buildpack-testrunner is doing, being enabled with upcoming process type support in CF. This would reduce barrier to run this test for new comers (being able to run them against run.pivotal.io) and possibly having the CI being public (e.g. travis). The faster bosh-lite or the flocker approaches having heavier associated setup costs.

Guillaume.

On Tuesday, August 12, 2014 6:31:02 PM UTC+2, rabdu...@pivotal.io wrote:

Hi Guillaume.

 

Does this answer your question regarding what's included and not? If not let me know.

The delta of changes with pointers to stories containing related github commits looks great.
 

Buildpack infrastructure is shared, and it differes greatly between JVM and non-jvm buildpacks.

The non-JVM buidlpack' infrastructure is prone to flux, so much that there are large API changes in the space of a single commit. Nonetheless, it's open and accessible. We currently have:

• Machete - a testing framework to integration test a buildpack and it's functionality.
• The Machete firewall test - that demonstrates simple use of Machete and of an ancilliary script for establishing an on-premises emulation in Bosh-Lite.
• Compile Extensions - A simple extension for caching dependencies
• Buildpack Packager - A simple extension to provide bin/package - a way to roll up dependencies in a pre-cached buildpack.

Let me quickly point out whats about to change.

Machete - We hope to make Machete test from within the Droplet environment. Currently an integration test through Bosh-Lite makes for very slow tests. We're not fans. We will make machete run tests in a VM with the same environment as the DEA, starting up warden containers which share the root filesystem with the buildpacks and fixture apps. This entirely mitigates the cost of copying buildpacks and apps throughout the entire cf system during a test.

It would be great to enable machete to run tests against a remote CF instance, similarly as what heroku-buildpack-testrunner is doing. This would reduce barrier to run this test for new comers (being able to run them against run.pivotal.io) and possibly having the CI being public (e.g. travis). The bosh-lite or the flocker approach see

 

[Rasheed Abdul-Aziz]

I think we're interested in simply abandoning the complete end to end solution and replacing it with CloudFocker. 

I've created a story that shares our internal process for setting up a build VM and testing/developing using CloudFocker (boy I hope they change it's name). https://www.pivotaltracker.com/story/show/77620166  

This way, the tool is 'dog fooded' - we use and maintain the same tool we hope others use. I don't think there is any point in maintaining the very slow integration suit that is Machete as it stands today.

Kind regards,

  Rasheed Abdul-Aziz