[JENKINS-73769] account for empty libraries or changed library path

[sboardwell]

This pull request:

• adds a new EMPTY status to the CacheStatus
• adds an additional empty check to the caching process of the LibraryAdder
• adds the notion of the libraryPath to the caching directory name
  • up until now, the same cache was return even if the libraryPath on the shared library configuration had changed
• adds tests

Steps to reproduce

libraryPath not considered

Consider a repo with multiple libraries

├── another-lib
│   └── vars
│       └── echoMe.groovy # echos "from another"
└── vars
    └── echoMe.groovy # echos "from root"

• add a library pointing to a the repo
• add a caching config of 5 mins
• try to use the library
  • pipeline echo's "from root"
  • subsequent builds with also echo "from root"
• change the "Library Path" field to another-lib
  • the wrong (old) pipeline is still checked and seen as cached
  • pipeline still echo's "from root" until the cache expires

Empty library on checkout

• add a library pointing to a the repo
• add a caching config of 5 mins
• ensure the library is pointing to a location without vars or src directories
  • for the sake of testing, add "vars" in the "Library Path" field (pretend it was a mistake)
• try to use the library
  • pipeline fails with "No vars or src directory"
  • subsequent builds with also fail until the cache expires
  • any other pipelines using that library will also fail

Empty library do to something unexpected

• add a library pointing to a the repo
• add a caching config of 5 mins
• try to use the library
  • pipeline echo's "from root"
  • subsequent builds with also echo "from root"
• manually delete the src and vars libraries cache directory (this is unexpected and just meant to represent something going wrong during retrieval)
  • pipeline fails with "No vars or src directory"
  • subsequent builds with also fail until the cache expires
  • any other pipelines using that library will also fail
• once the cache expires and the library is retrieved again, the builds will continue

Context

Although using the version which should have fixed the issue, some jobs have shown the following:

Loading library <library>
Library <library> is cached. Copying from home.
ERROR: Library <library> expected to contain at least one of src or vars directories
[Bitbucket] Notifying commit build result
[Bitbucket] Build result notified
Finished: FAILURE

• To be sure something has actually been retrieved, a check has been added post-retrieval.
• This way, if the retrieval somehow fails silently, the problem is still caught and thrown.
• In addition, a system log WARNING was added to allow easy discovery in this edge case.

Testing done

Tests added to PR.

Submitter checklist

• Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
• Ensure that the pull request title represents the desired changelog entry
• Please describe what you did
• Link to relevant issues in GitHub or Jira
• Ensure you have provided tests - that demonstrates feature works or fixes the issue

[rsandell]

I don't remember exactly how all the retrieval works, so I am wondering if this could potentially cause unnecessary retrieval to happen? E.g. One git repository containing five libraries would only be retrieved one time for each scm url ignoring libraryPath, and now with this change it will retrieve/cache one copy for each libraryPath? And that might not be desired?

[sboardwell]

Not as far as I can tell. The (SCM based) libraries are checked out:

• in the jobs own workspace
• only if needed (i.e. either caching not enabled, expired, or something else changed)

bash-4.4$ find -type d -name ".git" 
./workspace/test-pl3@libs/cd304ec6497d6f157eab60a432dcc6ecc1350d5f15d1fae9474b01115c211903/.git
./workspace/test-pl2@libs/cd304ec6497d6f157eab60a432dcc6ecc1350d5f15d1fae9474b01115c211903/.git
./workspace/test-pl@libs/cd304ec6497d6f157eab60a432dcc6ecc1350d5f15d1fae9474b01115c211903/.git

Library caching happens after checkout and the files land in a different directory (based on directoryName) and without the .git extras. Below two cached directories representing the vars under:

• https://github.com/sboardwell/demos/tree/main (root)
• https://github.com/sboardwell/demos/tree/main/build-storm (libraryPath = build-storm)

bash-4.4$ find global-libraries-cache/ -type f -newermt $(date +%Y-%m-%d) | sort -k 8
global-libraries-cache/2079b09ce5b9d359d406cb4c826fc11b39a8bb5c01398d55689261d81ebe1a11-name.txt
global-libraries-cache/2079b09ce5b9d359d406cb4c826fc11b39a8bb5c01398d55689261d81ebe1a11/last_read
global-libraries-cache/2079b09ce5b9d359d406cb4c826fc11b39a8bb5c01398d55689261d81ebe1a11/vars/deleteLibsDir.groovy
global-libraries-cache/2079b09ce5b9d359d406cb4c826fc11b39a8bb5c01398d55689261d81ebe1a11/vars/echoMe.groovy
global-libraries-cache/2079b09ce5b9d359d406cb4c826fc11b39a8bb5c01398d55689261d81ebe1a11/vars/rebaseRepos.groovy
global-libraries-cache/5a7d69d45c180afdf21fe343b63c3c3d4b7988c0dbc0ac83ff1d0977f7aba33f-name.txt
global-libraries-cache/5a7d69d45c180afdf21fe343b63c3c3d4b7988c0dbc0ac83ff1d0977f7aba33f/last_read
global-libraries-cache/5a7d69d45c180afdf21fe343b63c3c3d4b7988c0dbc0ac83ff1d0977f7aba33f/src/lostinberlin/TestClass.groovy
global-libraries-cache/5a7d69d45c180afdf21fe343b63c3c3d4b7988c0dbc0ac83ff1d0977f7aba33f/src/lostinberlin/TestEnum.groovy
global-libraries-cache/5a7d69d45c180afdf21fe343b63c3c3d4b7988c0dbc0ac83ff1d0977f7aba33f/vars/echoMe.groovy
global-libraries-cache/5a7d69d45c180afdf21fe343b63c3c3d4b7988c0dbc0ac83ff1d0977f7aba33f/vars/myPipeline.groovy
global-libraries-cache/5a7d69d45c180afdf21fe343b63c3c3d4b7988c0dbc0ac83ff1d0977f7aba33f/vars/rebuildOnDisconnect.groovy
global-libraries-cache/5a7d69d45c180afdf21fe343b63c3c3d4b7988c0dbc0ac83ff1d0977f7aba33f/vars/retryOnDisconnect.groovy
global-libraries-cache/5a7d69d45c180afdf21fe343b63c3c3d4b7988c0dbc0ac83ff1d0977f7aba33f/vars/updateBuildSchedule.groovy

[sboardwell]

@rsandell @jglick - is there anything else I can do on this PR?

[jglick]

I am not maintaining this plugin, especially not anything to do with caching which I do not think should have been introduced to begin with.

[rsandell]

I am still hoping for one more set of eyes to review this. Maybe @car-roll ?

[aneveux]

LGTM

FTR I am not a maintainer of that plugin and have very limited knowledge about it. I have read more code from that plugin to better understand how it works and played with the test and reproducer you provided to better understand your contribution and it looks great to me.

Thanks a lot @sboardwell for all the details in there!