Kh/dev/cache build pipeline

[bromiesTM]

• Change jfrog path to a non 'poc' path once review ok

[Copilot]

Pull request overview

This PR optimizes the Nextcloud Workspace build pipeline by implementing intelligent caching using GitHub Actions cache and JFrog Artifactory. Instead of rebuilding all apps on every run, the workflow now checks for cached build artifacts based on git submodule SHAs and only builds apps that have changed or lack cached artifacts. The optimization includes retry logic for JFrog uploads/triggers, workflow dispatch with force rebuild capability, and comprehensive cache status reporting.

Key Changes

• Implemented cache detection mechanism to identify which apps need building vs. can be restored from cache (GitHub Actions cache or JFrog)
• Added retry logic with exponential backoff for JFrog uploads and GitLab pipeline triggers
• Added workflow dispatch with force rebuild option to bypass all caches when needed

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 6 comments.

File	Description
.github/workflows/build-artifact.yml	Complete workflow refactoring with cache-aware building, conditional job execution, app restoration from JFrog/cache, retry logic, and force rebuild support
.github/scripts/detect-app-cache.sh	New script implementing cache detection logic that checks GitHub cache and JFrog for existing app builds and determines which apps need building

[Copilot]

The gh cache restore command does not exist in the GitHub CLI. Use the actions/cache/restore action instead, or implement a workaround since this is within a run script. Consider restructuring this as a separate step using the cache action.

Suggested change

	# Use actions/cache/restore in a way that works in a script context
	# We need to use gh CLI to restore the cache
	if gh cache restore "$CACHE_KEY" --key "$CACHE_KEY"; then
	echo "✅ Restored $APP_NAME from GitHub cache"
	# Validate restoration
	if [ ! -d "$APP_PATH" ] || [ ! -f "$APP_PATH/appinfo/info.xml" ]; then
	echo "❌ Validation failed for $APP_NAME"
	exit 1
	fi
	else
	echo "❌ Failed to restore from GitHub cache"
	exit 1
	fi
	# NOTE: Cannot restore GitHub cache from within a script.
	# Use the actions/cache/restore action as a separate step/job for each app.
	echo "❌ ERROR: Cannot restore GitHub cache from within a script. Please use actions/cache/restore in a separate step."
	exit 1

[Copilot]

The comment states delays are 10s then 20s, but the logic produces delays of 10s, 20s, and 40s across three attempts. The comment should be updated to accurately reflect the actual exponential backoff pattern: '10s, 20s, 40s'.

Suggested change

	DELAY_SEC=$((DELAY_SEC * 2)) # Exponential backoff: delays are 10s, then 20s (sleep occurs after failed attempts)
	DELAY_SEC=$((DELAY_SEC * 2)) # Exponential backoff: delays are 10s, 20s, 40s (sleep occurs after failed attempts)

[Copilot]

The comment states delays are 5s, 10s, 20s, but with three attempts the actual delays between retries are only 5s and 10s (two retries after the first failure). The comment should clarify that these are the delays between the 3 attempts, not 4 attempts.

Suggested change

	DELAY_SEC=$((DELAY_SEC * 2)) # Exponential backoff: 5s, 10s, 20s
	DELAY_SEC=$((DELAY_SEC * 2)) # Exponential backoff: delays between attempts are 5s, 10s (for 3 attempts)

[Copilot]

Using --key as a filter in gh cache list requires an exact match, but the intention seems to be finding a cache with this specific key. Consider using --key as a prefix matcher or verify that the exact key matching is intentional and document this behavior.

Suggested change

	# Include --ref to access caches from the current ref (branch, PR, etc.)
	# Include --ref to access caches from the current ref (branch, PR, etc.)
	# NOTE: We intentionally use --key for exact cache key matching.
	# Only exact matches are considered valid for restore; prefix fallback is not used.

[seriAlizations]

LGTM but please fix spelling errors