prime error: unable to set version: it was already set in the 'build' step

This is still an issue:

Updating build step for nymea-app ('pull' step changed)
++ git -C /root/parts/nymea-app/src describe --tags
+ snapcraftctl set-version 1.0.272-2-g94acae8a
Unable to set version: it was already set in the 'build' step.
Run the same command again with --debug to shell into the environment if you wish to introspect this failure.

The relevant yaml:

base: core20
...
    override-build: |
      snapcraftctl set-version $( git -C ${SNAPCRAFT_PART_SRC} describe --tags )
      snapcraftctl build

I was unable to reproduce it now.

I also tried to reproduce with multipass and nymea-app without success. Changes to the source tree *during* the snap build, however, can have unpredictable results and could cause problems such as this one. Maybe something like this could have happened in this case?

Don't believe so, no… And doesn't Snapcraft _copy_ the code in the pull step anyway?

Snapcraft 6.x copies (pulls) the source, but it also checks for outdated source files as the parts lifecycle processing is executed. This could cause the copied source to be updated and rebuilt, which could potentially result in the duplicated version setting. This strategy was changed in Snapcraft 7 for core 22.

I also have seen the same problem while building kernel-snap. The problem occurs when I re-build the kernel snap once a previous build fails.

The content of the snapcraft.yaml:

```
override-build: |
  snapcraftctl build
  snapcraftctl set-version "xxx-$(head -n1 ${SNAPCRAFT_PART_SRC}/debian.xxx/changelog | cut -f2 -d\( | cut -f1 -d\))"
```

Output of the log:
```
snapcraftctl set-version xxx-5.4.0-1028.39
Unable to set version: it was already set in the 'build' step.
```

The snapcraft version is: 7.2.9.

No, snapcraft "pull" doesn't just copy, it uses hardlinks

https://bugs.launchpad.net/shiner/+bug/1999091

pull clones into parts/<part name>/src
but from there onwards it's hard links into parts/<part name>/build
then build installs files into parts/<part name>/install
and from there it's hard links to stage and prime

However kernel plugging avoids any links between parts/<part name>/src and
parts/<part name>/build

On Thu, 8 Dec 2022 at 15:45, Dean Matsen <email address hidden> wrote:

> No, snapcraft "pull" doesn't just copy, it uses hardlinks
>
> https://bugs.launchpad.net/shiner/+bug/1999091
>
> --
> You received this bug notification because you are a member of Snappy
> Developers, which is subscribed to Snapcraft.
> https://bugs.launchpad.net/bugs/1831135
>
> Title:
> prime error: unable to set version: it was already set in the 'build'
> step
>
> Status in Snapcraft:
> Invalid
>
> Bug description:
> Trying to build Multipass with the following patch:
> http://paste.ubuntu.com/p/PzMKxvpw2m/ to trigger "new" snapcraft.
>
> Having built, trying to `snapcraft prime` I end up with:
>
> Unable to set version: it was already set in the 'build' step.
> Failed to run 'override-build': Exit code was 2.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/snapcraft/+bug/1831135/+subscriptions
>
>

I have a version of this bug with `base: core22`, maybe the logs will help.

I triggered it by flipping from `override-build:` to `override-pull:` where `craftctl set version=…` is called.

This bug can be triggered in core22 with the following reproducer:

parts:
  part1:
    plugin: nil
    override-pull: |
      craftctl default
      craftctl set version=xx

  part2:
    plugin: nil
    after: [part1]

After running the lifecycle successfully, change something in part1 to make the part dirty (e.g. add "echo" at the end of the pull scriptlet), and build only part2. Part1 will be pulled after part2 (because it's dirty), reversing the order these two parts were pulled when states were built, and set version will be executed when state is already set for the version variable.

This doesn't happen in core20, even if build attribute core22-step-dependencies is used. This needs investigation to see if core22 can be changed to work in a similar way.

Still no reproducers found for the original problem reported for core20.