Forcefully pull / build a part even if it is run previously

During snapcraft build, is there a way to forcefully pull a part even if it has been pulled / built / staged and primed successfully in the previous run’s?

Have a look at snapcraft clean --help - you can clean just one part.

I know about clean. What I am looking for is the part to be always pulled and built w/o having to clean it.
Simply put, every time a snapcraft is run, the part should be freshly pulled and built even if it was built before.

Then no, not that I know of. Can you explain your use case please?

I am using adopt-info feature of snapcraft to set version of the snap. adopt-info takes part as an argument. In this part, I run a script to determine and set version. When build is run this part runs in which a script is executed that calls snacraftctl set-version <string> which sets the version of snap. A new version is set every time there is a change in any files in the repo.

Use case (where above new version is not getting set):

  1. Pull a new repo
  2. Build a snap w/o change. This triggers the above part to run and set a version.
  3. Change any file
  4. Rerun build (w/o snapcraft clean)

Although, a file has changed, version does not get changed. This is because the part that sets the version does not run in the build because it was already run and there is no change in it.

Hence I am looking at a mechanism to force run a part by default w/o checking anythig.

it might break everything and i’m not sure it will work at all, but you could try to have an override-build: snippet that calls snapcraftctl pull before snapcraftctl set-version

Should have given this snippet earlier.
My script that sets version is being called in override-pull already. Did you mean me do to something different that this?

adopt-info: os-build-scripts

    plugin: nil                                                                    
    source: ssh://git@<XYZ>/os-build-scripts.git             
    override-pull: |                                                               
        snapcraftctl pull                                                          
        cp $SNAPCRAFT_PROJECT_DIR                                  
        cd $SNAPCRAFT_PROJECT_DIR                                                  
    override-prime: |                                                              
        snapcraftctl prime                                                         
        rm -rf                                                     
        rm -rf $SNAPCRAFT_PROJECT_DIR/

move the version generation to override-build and then try to call the snapcraftctl pull in it before setting the version … i suspect this might confuse snapcraft though but perhaps at least worth a try …

Thanks, but did not work.
Skipping build os-build-scripts (already ran)

Since the part is unchanged, no operations will be performed on it.

ah, so snapcraft is cleverer than i thought …

Yes it is :blush: That is why I am looking at a way to force build the part w/o any checks.

We do have plans to eventually introduce

  • re
  • un

Or something similar. We have not prioritized it as with local sources, at least in core20, we now just always refresh sources.

1 Like

It’s a bit of a hack, but you might try adding an override-pull script to every part that touches a file inside the set-version part’s local directory by absolute path starting from $SNAPCRAFT_PROJECT_DIR (I realize it is not currently a local directory but you could make it one) (of course each of these would also include snapcraftctl pull to ensure the normal pull function executes for the part). Then, order the set-version part so that it runs after every other part. My thinking is that if any part gets pulled, it will change this dummy file in set-version, which then causes set-version to run every time.

Thanks @kyleN, but even if this works, this would mean copying the version script in each repo to have it locally (I have 15 repo’s in all). This will kill my purpose of isolating the versioning repo (so that I have control in one place) from other repo’s and add maintenance overhead.