Note: This PR has the cherry-picked changes from @abe-winter 's original PR #9450.

Before parsing the Dockerfile to extract dependencies, Skaffold generates a list of build arguments for the Dockerfile. These arguments did not previously include [IMAGE_REPO,IMAGE_NAME,IMAGE_TAG] which the document states should be available. This PR makes changes so that these build args are available when extracting dependencies from the Dockerfile.

Overview:

The build args are evaluated by the SourceDependenciesCache.SingleArtifactDependencies interface method. This method is in turn called by CheckArtifacts in the skaffold diagnose command and within the depLister function

The depLister is a function used to get dependencies of a docker image. It implements the DependencyLister func interface.
Its overwritten by a stub implementation in some unit tests.

Changes:

The IMAGE_REPO,IMAGE_NAME_IMAGE_TAG variables are derived from the fully-qualified docker tag for the image.
Previously, the dependencies for the dockerfile were fetched before the tag was generated. The logic used to generate the image tag was moved out of its pkg/skaffold/runner/build.go within the Builder struct and turned into a callable utility method. This is now located in the util package pkg/skaffold/util/util.go.

The depLister function signature was changed to also accept a tag argument to propagate it to the SingleArtifactDependencies struct. The methods that implement depLister were changes to match the new signature. For ex. files in pkg/skaffold/build/cache, and pkg/skaffold/tag.

Diagnose: The diagnose implementation now generate the tags for the images to be built and passes the appropriate tag to SingleArtifactDependencies when its called.

Unit Tests:

Added unit test in dependencies_test.go to directly the new functionality in SingleArtifactDependencies.

Other tests don't test SingleArtifactDepencies directly but use a fake implementation of the depLister function. So the only thing I did here was to change the function signature of the stub to add the tag parameter.

Integration Tests:

In integration/build_test.go:

• Added integration test to check that the [IMAGE_REPO,IMAGE_NAME,IMAGE_TAG] build args are properly evaluated and passed to the docker image.

• Added second integration test to ensure that IMAGE_TAG can be used as part of a file to be copied from the host to the docker image.

Miscellaneous Bug Fixes:

• Added 2025 as a valid year in the hack/boilerplate/boilerplate.py script that checks the copyright notice.

• In pkg/skaffold/deploy/helm: Fix flaky test by sorting the order of releases and so that helm commands are called in consistent order.

Original PR Description

Related:

• related fix for kaniko Make IMAGE_REPO, IMAGE_NAME, IMAGE_TAG available in build.artifacts[i].docker.buildArgs #4295
• related fix fix: Fill IMAGE_TAG,etc on Docker builds #7788

Description
Apologies if I am simply misunderstanding something and this can be fixed w/out a code change. I am certainly not fully wrapping my head around this codebase.

This PR adds the ability to use IMAGE_TAG (IMAGE_REPO etc) in the docker buildArgs section, specifically when the build arg is then consumed in the Dockerfile FROM. On current stable and main, this case fails in the depList / SingleArtifactDependencies phase, with logs like:

Checking cache...

• base: Found Remotely
• child: Error checking cache.

getting hash for artifact "child": getting dependencies for "child": parsing ONBUILD instructions: retrieving image "gcr.io/headsdown/base:": parsing reference "gcr.io/headsdown/base:": could not parse reference: gcr.io/headsdown/base:

Note that when used with dependencies (as below), this seems to only work reliably if I run skaffold build && skaffold run. skaffold run by itself will sometimes fail with 'image not found remotely'.

Repro

Stripped-down skaffold.yaml:

build:
  local:
    useBuildkit: true
  artifacts:
    - image: base
      docker:
        dockerfile: Dockerfile
    - image: child
      requires:
      - image: base
      docker:
        dockerfile: child/Dockerfile
        buildArgs:
          IMAGE_TAG: '{{.IMAGE_TAG}}'

Top of child/Dockerfile:

# syntax=docker/dockerfile:1
ARG IMAGE_TAG
FROM gcr.io/PROJECTNAME/base:$IMAGE_TAG

tldr the second artifact depends on the first and then uses it as a base image

User facing changes
I think the docs already imply this is possible

Follow-up Work
No idea if I'm conforming to house style -- if accepted, guessing someone on the team will need to clean up or at least assign me cleanup. I would normally have submitted a bug rather than a PR for something like this, but I didn't understand why my template param was missing until I'd already solved the problem.

If this is something useful, happy to add tests etc.

@alphanota : We might want to add integration tests to check that the build args are resolved correctly.