Test Data for DigiKam

[Steven Robbins]

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 at riemann:~/projects/digikam$ echo $GITSLAVE
steve at 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 at riemann:~/projects/digikam$ git checkout feature-qtav-testing 
steve at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/digikam-devel/attachments/20220928/e80ef7fb/attachment.sig>