Re: Test Data for DigiKam

Hi Steve,

Hum, your are right, I remember that working with branches is the hell.

I looking if gitslave still maintained and... no, since 2012:

https://gitslave.sourceforge.net/

The right alternative to use is git sub-modules. I think the right
documentation for gitlab is here :

https://docs.gitlab.com/ee/ci/git_submodules.html

As a sub module, we don't need any documentation repository at all.
Only unit test data repository is required. Using sub-modules will
work with branches.

And finally, the "gitslave" rules can be removed in the source code repository.

Best

Gilles

Le jeu. 29 sept. 2022 à 04:27, Steven Robbins <[email protected]> a écrit :
>
> On Wednesday, September 28, 2022 12:43:44 A.M. CDT Gilles Caulier wrote:
>
> Hello ... just had a moment to try the script.
>
> > To checkout source and doc, developers will use the "download-repos"
> > script, which is called "gits" script. This last one will parse the
> > .gitslave configuration file to process multiple checkouts locally.
> > Note that developers need to patch previously the .bashrc
> > configuration with "export GITSLAVE=.gitslave" definition, else it
> > will not work.
>
> Is that still accurate?
> I didn't set GITSLAVE, yet it appears to work:
>
> steve@riemann:~/projects/digikam$ echo $GITSLAVE
> steve@riemann:~/projects/digikam$ ./download-repos
> Cloning into 'doc'...
> remote: Enumerating objects: 6914, done.
> remote: Counting objects: 100% (28/28), done.
> remote: Compressing objects: 100% (22/22), done.
> remote: Total 6914 (delta 9), reused 21 (delta 6), pack-reused 6886
> Receiving objects: 100% (6914/6914), 141.89 MiB | 2.55 MiB/s, done.
> Resolving deltas: 100% (3015/3015), done.
>
> However, it does NOT work if on a feature branch:
>
> steve@riemann:~/projects/digikam$ git checkout feature-qtav-testing
> steve@riemann:~/projects/digikam$ ./download-repos
> Cloning into 'doc'...
> [...]
> Resolving deltas: 100% (3015/3015), done.
> Switching "" to branch "feature-qtav-testing"
> fatal: 'origin/feature-qtav-testing' is not a commit and a branch 'feature-
> qtav-testing' cannot be created from it
> Branch inconsistency, branch feature-qtav-testing does not exist for doc
>
> - Failed to populate gits repositories, aborting.
>
> > And if we append the url to .gitslave, this repo will be downloaded
> > automatically with source code.
>
> > > So: can we devise a mechanism where we run lower-frequency (once per day?)
> > > test jobs to get this coverage?
>
> Turns out that is very easy [1].  One can even set up variables.  We could set
> a variable to mean "run the expensive tests" and use that in the cmake script
> to trigger running "download-repos".
>
> [1] https://invent.kde.org/help/ci/pipelines/schedules.md
>
> > > That would require the CI "checkout"
> > > mechanism to pull down this second repo in some fashion.  Is that do-able?
> >
> > Certainly, but all the in-deep CI settings must be configured in a
> > special place managed by system admin.
>
> Are you referring to CI settings to make sure perl (and whatever else
> "download-repos" needs) ?  Or something else?
>
> -Steve