CODEWITHSUNDEEP
bitbucketbitbucket-pipelinesbuildpack
Cody
Cody

Reputation: 11

Using CNCF Buildpacks on Bitbucket Pipelines

I'm experimenting with CNCF Buildpacks' pack tool to generate container images in BitBucket pipelines but I'm getting the following error:

ERROR: failed to build: failed to create 'creator' container: Error response from daemon: authorization denied by plugin pipelines: -v only supports $BITBUCKET_CLONE_DIR and its subdirectories"

It seems like buildpacks has support to define specific mount directories for some of the mount points for the caches which I can set to the clone directory for bitbucket however there are some mount points I can't seem to find configurable.

Using build cache dir '/opt/atlassian/pipelines/agent/build/build-cache'
Build cache '/opt/atlassian/pipelines/agent/build/build-cache' cleared
Created ephemeral bridge network pack.local-network-<id> with ID <id>
Running the 'creator' on OS 'linux' from image 'pack.local/builder/<id>:latest' with:
Container Settings:
  Args: '/cnb/lifecycle/creator -daemon -launch-cache /launch-cache -log-level debug -app //opt/atlassian/pipelines/agent/build -cache-dir /cache -run-image index.docker.io/paketobuildpacks/run-jammy-base:latest -skip-restore <project>'
  System Envs: 'CNB_PLATFORM_API=0.13'
  Image: 'pack.local/builder/<id>:latest'
  User: 'root'
  Labels: 'map[author:pack]'
Host Settings:
  Binds: '/opt/atlassian/pipelines/agent/build/build-cache:/cache /var/run/docker.sock:/var/run/docker.sock /opt/atlassian/pipelines/agent/build/launch-cache/launch-cache:/launch-cache pack-layers-<id>:/layers pack-app-<id>://opt/atlassian/pipelines/agent/build'
  Network Mode: 'pack.local-network-<id>'
ERROR: failed to build: executing lifecycle: failed to create 'creator' container: Error response from daemon: authorization denied by plugin pipelines: -v only supports $BITBUCKET_CLONE_DIR and its subdirectories

Seems like layers- is mounted to /layers which is obviously out of the BitBucket clone directory.

I find this a little perplexing because I have maven builds which also use pack but don't experience the same issue, and I feel like I've configured my run command to do similar. I'm also not sure if the /var/run/docker.sock:/var/run/docker.sock mount is acceptable either.

I've tried different buildpacks and defining which buildpacks are used at runtime and defining the cache locations (which is the workaround for maven builds).

All have resulted in the same error.

This build also works locally on my machine.

I'm pretty out of ideas at this point so any help would be great.

Upvotes: 1

Views: 21

Answers (1)

Daniel Mikusa
Daniel Mikusa

Reputation: 15051

I don't use Bitbucket myself, but it sounds like your CI jobs are running in containers themselves. This is a little tricky with Cloud-Native buildpack tooling like pack because some of its functionality expects a Docker daemon. This is often difficult, slow, or just not possible when you're already running in a container.

The pack tool is what's called a "platform". Its job is to get everything ready to run a build with CNBs, so it will fetch base & run images, fetch buildpack images, and configure a clean container environment in which to run your build. There are other platforms, like kpack and Spring Boot's Build Tools. You can also be your own platform with a little bit of scripting. These platforms are just the tools for setting up the build, though, they don't actually run buildpacks, they delegate to a tool called the CNB lifecycle which does the actual work of running buildpacks.

So in a situation like what you're describing where your CI jobs are already running in containers, what I usually see people do is treat the job's container as the build environment and run the Cloud-Native buildpacks directly there, i.e. skip pack.

This roughly looks like the following (in your CI build job):

  1. Set your CI to use your CNB Builder image as it's base image. This means your job will run in an environment where it already has some buildpacks.
  2. Download the lifecycle, https://github.com/buildpacks/lifecycle/releases
  3. Download or check out your app code. If you built the app in a previous step, maybe you're downloading the compiled binary or JAR file or whatever gets put into the app container. It doesn't have to be source code, just whatever you want the buildpacks to take and turn into an app image.
  4. Run the lifecycle's creator. This is a one-shot build that runs all the steps for you. You can also run the CNB build steps individually, but that's not usually necessary.

The lifecycle will run the buildpacks and then export the image. Because there is no docker daemon, you must point it to a registry where it can upload the image.

That's it in a nutshell. There is a lot more detail and a walkthrough of this on this page of the CNB documentation, and on this blog post.

Upvotes: 0

Related Questions