Create pull requests to update buildpacks in Cloud Foundry manifest files, Halfpipe pipelines, and GitHub Actions workflows.

Aiming for reproducible deployments it's a necessary step to pin a buildpack in a project to a specific version, so it will always use the one you specify.

The disadvantage of pinning is that any improvement in a newer version is not automatically taken over to the project.

With this GitHub action a pull request will be created if there is a newer version of a buildpack available. That way the project can stay up-to-date but with a conscious and deliberate change, traceable in version control.

The action scans the repository for buildpack references in three places:

Pinned classic CF buildpacks referenced by GitHub URL and version tag:

applications:
  - name: my-app
    buildpacks:
      - https://github.com/cloudfoundry/java-buildpack#v4.50.0

Pinned Paketo buildpacks in buildpack tasks:

tasks:
  - type: buildpack
    image: eu.gcr.io/halfpipe-io/my-team/my-app
    buildpacks:
      - paketo-buildpacks/java:21.4.0

Pinned Paketo buildpacks passed to steps via the buildpacks input (e.g. when using ee-action-buildpack):

- name: Pack n Push
  uses: springernature/ee-action-buildpack@v1
  with:
    buildpacks: paketobuildpacks/java:21.4.0

Note: By default, buildpack updates found in GitHub Actions workflow files are detected and reported in the job summary only — no PR is created. This is because modifying .github/workflows/ files requires the GitHub Workflows permission, which is not available to a standard GITHUB_TOKEN.

To enable automatic PR creation for workflow file updates, set UPDATE_WORKFLOW_FILES=true and use a GitHub App that has the "Workflows: Read and write" permission (see Opt-in: updating workflow files below).

Create a file in your repo called .github/workflows/buildpack-update.yml and in it put this code (remember to update [email protected] to one that is correct for your team)

name: buildpack-update
on:
  schedule:
    - cron: '0 4 * * 1-5' # Every workday at 04:00 UTC
  workflow_dispatch:

jobs:
  buildpack_updates_job:
    runs-on: ee-runner
    timeout-minutes: 30
    name: buildpack updates
    steps:
      - name: Check out the repo
        uses: actions/checkout@v4
      - name: run cf-buildpack-update-action
        uses: springernature/[email protected]
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          AUTHOR_EMAIL: [email protected]
          AUTHOR_NAME: Buildpack Update Action
          GITHUB_STEP_SUMMARY_ENABLED: true

This should be picked up automatically in GitHub as a new Action and produce a PR (Pull Request) with the buildpack version changes whenever a new version is available. Just accept and merge the PR and you will be up-to-date.

From GitHub documentation:
If you do want to trigger a workflow from within a workflow run, you can use a GitHub App installation access token or a personal access token instead of GITHUB_TOKEN to trigger events that require a token. So, if the opened PR should run some automated tests, you will need a PAT (Personal Access token) or a GitHub app installation access token instead of the normal GitHub token.

When setting GITHUB_STEP_SUMMARY_ENABLED to true (default is false) a job summary is created, see example output.

By default the action only detects and reports Paketo buildpack updates found in .github/workflows/ files. It does not attempt to create PRs for them.

To opt in to automatic PR creation for workflow file updates, two things are required:

1. A GitHub App that has the "Workflows: Read and write" permission installed on your repository.
2. The UPDATE_WORKFLOW_FILES=true environment variable set on the action step.

GitHub enforces that any push modifying files under .github/workflows/ must be authorised by a token whose underlying credential has the workflows scope. The built-in GITHUB_TOKEN never has this scope. There is no workflows: key in the workflow-level permissions: YAML block — it must be granted at the GitHub App installation level.

name: buildpack-update
on:
  schedule:
    - cron: '0 4 * * 1-5'
  workflow_dispatch:

jobs:
  buildpack_updates_job:
    runs-on: ee-runner
    timeout-minutes: 30
    name: buildpack updates
    steps:
      - name: Generate app token
        id: app-token
        uses: actions/create-github-app-token@v1
        with:
          app-id: ${{ vars.MY_APP_ID }}
          private-key: ${{ secrets.MY_APP_PRIVATE_KEY }}

      - name: Check out the repo
        uses: actions/checkout@v4
        with:
          token: ${{ steps.app-token.outputs.token }}

      - name: run cf-buildpack-update-action
        uses: springernature/[email protected]
        env:
          GITHUB_TOKEN: ${{ steps.app-token.outputs.token }}
          AUTHOR_EMAIL: [email protected]
          AUTHOR_NAME: Buildpack Update Action
          GITHUB_STEP_SUMMARY_ENABLED: true
          UPDATE_WORKFLOW_FILES: true

The GitHub App must be installed with the "Workflows: Read and write" permission in addition to the usual "Contents: Read and write" and "Pull requests: Read and write" permissions.

You can configure dependabot to keep your action which uses cf-buildpack-update-action up-to-date for every new version on cf-buildpack-update-action.

Enabling Dependabot version updates for actions — Keeping your actions up to date with Dependabot - GitHub Docs

Enabling Dependabot version updates for actions

1. Create a dependabot.yml configuration file. If you have already enabled Dependabot version updates for other ecosystems or package managers, simply open the existing dependabot.yml file.
2. Specify "github-actions" as a package-ecosystem to monitor.
3. Set the directory to "/" to check for workflow files in .github/workflows.
4. Set a schedule.interval to specify how often to check for new versions.
5. Check the dependabot.yml configuration file in to the .github directory of the repository. If you have edited an existing file, save your changes.

Before submitting any pull requests, please ensure that you have adhered to the contribution guidelines.

• enhance documentation
• have an automated release process?
• improve build time
• make it configurable, see Dependabot config for ideas

GPL 3

Copyright Springer Nature