[regression] Running kaniko with option --cache-copy-layers=true causes build error and failed pipeline on GitLab CI when Dockerfile contains more than one COPY directive

[LeTraceurSnork]

Actual behavior Running kaniko with option --cache-copy-layers=true causes build error and failed pipeline on GitLab CI when Dockerfile contains more than one COPY directive

Expected behavior The same, but since that behavior is clearly backwards incomatible, release MUST BE major due to semver

To Reproduce Steps to reproduce the behavior:

1. Create Dockerfile with more than one COPY layer
2. Run kaniko with --cache-copy-layers=true to build this image

Additional Information

• Dockerfile

  
  FROM composer:2.4.1 as composer
  FROM wordpress:6.0.2-php8.1-apache

WORKDIR /usr/src/wordpress

Copy Everything we need

COPY . ./

Composer installation

COPY --from=composer /usr/bin/composer /usr/bin/composer

RUN composer install

 - Build Context
   Multistage build, first copying all the files to Wordpress root directory, then copying `composer` (executable) to `/usr/bin/` and installing dependencies
 - Kaniko Image (`gcr.io/kaniko-project/executor:debug` - v1.9.1 latest)

 **Triage Notes for the Maintainers**
 <!-- 🎉🎉🎉 Thank you for an opening an issue !!! 🎉🎉🎉
We are doing our best to get to this. Please help us by helping us prioritize your issue by filling the section below -->

 | **Description** | **Yes/No** |
 |----------------|---------------|
 | Please check if this a new feature you are proposing        | <ul><li>- [ ] </li></ul>|
 | Please check if the build works in docker but not in kaniko | <ul><li>- [x] </li></ul>| 
 | Please check if this error is seen when you use `--cache` flag | <ul><li>- [x] </li></ul>|
 | Please check if your dockerfile is a multistage dockerfile | <ul><li>- [x] </li></ul>| 

[gomzyakov]

If you stick to semantic versioning, then:

PATCH version when you make backwards compatible bug fixes

This change really breaks backwards compatibility.

[LeTraceurSnork]

@chuangw6 please check this as you were release-master

[jbg]

The closest thing I could find to a versioning policy in this repo is

In most cases, you will need to bump the VERSION_MINOR number. In case you are doing a patch release for a hot fix, bump the VERSION_BUILD number.

in https://github.com/GoogleContainerTools/kaniko/blob/main/RELEASE.md.

So I think your assumption that this project follows semver and the release "MUST BE major" is probably unfounded.

It would be good if maintainers could clarify the versioning policy (and ideally commit to following semver to avoid unexpected breakage in people's build pipelines).

[aaron-prindle]

Sorry for the issues you had here @LeTraceurSnork. I believe it was incorrect to release this as v1.9.1 when it likely should have been v1.10.0. The most recent releases (v1.10.0, v1.11.0) are following the correct semver usage bumping the minor version number (VERSION_MINOR in the Makefile). The breaking changes you encountered were likely related to an unintentioal regression which we can work to fix. I will re-title this issue to relate to the specific issue you encountered