Add automation to re-generate sample builders when lifecycle is published

[natalieparellano]

Description

This will ensure the sample builders are kept up-to-date with the lifecycle.

Proposed solution

Slack thread

Can I propose that the #implementation team add automation to have this done similar to how we do with pack releases?
See here and here.
Additionally, we’d need to update the builder.toml files to set an explicit version of the lifecycle instead of relying on pack’s default since they don’t typically correlate.

[Dhruv-Sachdev1313]

Hey @natalieparellano, Would love to work on this one, Can you please explain this a little, I am unable to access slack thread!

[natalieparellano]

@Dhruv-Sachdev1313 that is awesome to hear!

At a high level, this is about setting up collaboration between buildpacks/lifecycle and buildpacks/samples, so that we always pull in the latest lifecycle.

On buildpacks/lifecycle, we'll want to send a lifecycle-release dispatch, similar to what pack does here: https://github.com/buildpacks/pack/blob/main/.github/workflows/delivery-release-dispatch.yml

On buildpacks/samples, when we register the event, we'll want to rebuild the samples, by adding lifecycle-release on or about here: https://github.com/buildpacks/samples/blob/aa79de59c4bae24e32f15fda467d02ae9cd94b01/.github/workflows/build-and-deploy.yml#L10-L12

pack build will download the lifecycle with version matching pack's hard-coded "default lifecycle version", and since pack isn't typically updated immediately upon releasing the lifecycle we'll need to specify the lifecycle version explicitly to get the latest.

• We'll need to detect the new lifecycle version somehow and set it in the workflow environment.
• Then, we'll want to update the builder files to contain something like:

# Uncomment to specify the lifecycle version
#[lifecycle]
#version = "REPLACE"

and we can do the editing as part of the workflow.

I hope this is helpful - please feel free to reach out further if you have any questions. cc @buildpacks/learning-maintainers as this contribution also affects their repo :)

[glokta1]

Hi @natalieparellano,
Had some questions regarding the implementation:

1. Would you prefer if I create a new workflow file for sending dispatch events or integrate it into post-release.yml itself?
2. Are we sending the dispatch events to just buildpacks/samples or the other repos too? If I understand correctly, can't we just update the files where "Default Lifecycle Version" is defined in pack when receiving the lifecycle-release dispatch? Then, there is no need to update all the builder samples.
3. Where is the default lifecycle version in pack defined? I looked through some commits and found this: https://github.com/buildpacks/pack/blob/33f0aabe6f5dad502252329f674fc1edbf8baf52/internal/builder/lifecycle.go#L17. Is this all or are there other places too?

Thanks!

[natalieparellano]

Hi @glokta1! I think a new workflow file will be fine. For this issue, we just want to send the dispatch to buildpacks/samples. We will eventually need to update DefaultLifecycleVersion in pack (we could make a separate issue for a workflow where new lifecycle releases will create a PR to buildpacks/pack to update the constant) but that change would need to be reviewed, merged, and scheduled for the next release before it will be useful to buildpacks/samples consumers. Hence overriding the [lifecycle] in each builder.toml will let us use the new lifecycle immediately, without having to wait for a new pack release.

[natalieparellano]

Alternative idea: add a --lifecycle flag to pack that would override the lifecycle used for ALL phases (not just analyze/restore/export which is what --lifecycle-image is for and only works for untrusted builder workflows). This would allow us to exercise a new lifecycle before a new pack is published, and would be easier than a find/replace in each builder.toml.

Possibly we could move this issue over to pack so that the work could be done there first - @jjbustamante @buildpacks/platform-maintainers WDYT?