smanders/externpro with ghactions

[smanders]

issue externpro/externpro#129

[smanders]

boost: update DLURL build failure on linux

ls: cannot access '_bld-Linux/externpro*-devel.tar.xz': No such file or directory

since externpro .tar.xz files don't have COMPONENT devel set, they aren't truly devel packages

build-[linux|windows].yml were modified to not be so specific about finding devel
externpro/externpro@659f73d

this commit was made in a legacy branch of externpro because I hope this workaround dies with smanders/externpro

[smanders]

build-windows is failing during "CMake Workflow" step

Executing workflow step 2 of 6: build preset "WindowsDebug"

MSBuild version 17.14.14+a129329f1 for .NET Framework

C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Microsoft\VC\v170\Microsoft.CppBuild.targets(459,5): error MSB8013: This project doesn't contain the Configuration and Platform combination of Debug|x64. [D:\a\externpro\externpro\_bld-Windows\ZERO_CHECK.vcxproj]

the fix was to pass WindowsRelease as the cmake-workflow-preset ... smanders/externpro runs cmake for each project and configures for Release and Debug at that point https://github.com/externpro/externpro/blob/25.04/cmake/xpfunmac.cmake#L506-L550

[smanders]

linux-arm64 build is failing on "Upload devel tarball artifact" step

Failed to CreateArtifact: Received non-retryable error: Failed request: (409) Conflict: an artifact with this name already exists on the workflow run

because the name of the externpro tar.xz file is the same for both linux and linux-arm64...

[smanders]

linux clean-up job is failing

/usr/bin/docker run --name ghcriosnokcontainerretentionpolicyv300_82ff93 --label a5299f --workdir /github/workspace --rm -e "INPUT_ACCOUNT" -e "INPUT_TOKEN" -e "INPUT_IMAGE-NAMES" -e "INPUT_TAG-SELECTION" -e "INPUT_CUT-OFF" -e "INPUT_DRY-RUN" -e "INPUT_IMAGE-TAGS" -e "INPUT_SKIP-SHAS" -e "INPUT_KEEP-N-MOST-RECENT" -e "INPUT_TIMESTAMP-TO-USE" -e "INPUT_RUST-LOG" -e "RUST_LOG" -e "HOME" -e "GITHUB_JOB" -e "GITHUB_REF" -e "GITHUB_SHA" -e "GITHUB_REPOSITORY" -e "GITHUB_REPOSITORY_OWNER" -e "GITHUB_REPOSITORY_OWNER_ID" -e "GITHUB_RUN_ID" -e "GITHUB_RUN_NUMBER" -e "GITHUB_RETENTION_DAYS" -e "GITHUB_RUN_ATTEMPT" -e "GITHUB_ACTOR_ID" -e "GITHUB_ACTOR" -e "GITHUB_WORKFLOW" -e "GITHUB_HEAD_REF" -e "GITHUB_BASE_REF" -e "GITHUB_EVENT_NAME" -e "GITHUB_SERVER_URL" -e "GITHUB_API_URL" -e "GITHUB_GRAPHQL_URL" -e "GITHUB_REF_NAME" -e "GITHUB_REF_PROTECTED" -e "GITHUB_REF_TYPE" -e "GITHUB_WORKFLOW_REF" -e "GITHUB_WORKFLOW_SHA" -e "GITHUB_REPOSITORY_ID" -e "GITHUB_TRIGGERING_ACTOR" -e "GITHUB_WORKSPACE" -e "GITHUB_ACTION" -e "GITHUB_EVENT_PATH" -e "GITHUB_ACTION_REPOSITORY" -e "GITHUB_ACTION_REF" -e "GITHUB_PATH" -e "GITHUB_ENV" -e "GITHUB_STEP_SUMMARY" -e "GITHUB_STATE" -e "GITHUB_OUTPUT" -e "RUNNER_OS" -e "RUNNER_ARCH" -e "RUNNER_NAME" -e "RUNNER_ENVIRONMENT" -e "RUNNER_TOOL_CACHE" -e "RUNNER_TEMP" -e "RUNNER_WORKSPACE" -e "ACTIONS_RUNTIME_URL" -e "ACTIONS_RUNTIME_TOKEN" -e "ACTIONS_CACHE_URL" -e "ACTIONS_RESULTS_URL" -e GITHUB_ACTIONS=true -e CI=true -v "/var/run/docker.sock":"/var/run/docker.sock" -v "/home/runner/work/_temp/_github_home":"/github/home" -v "/home/runner/work/_temp/_github_workflow":"/github/workflow" -v "/home/runner/work/_temp/_runner_file_commands":"/github/file_commands" -v "/home/runner/work/externpro/externpro":"/github/workspace" ghcr.io/snok/container-retention-policy:v3.0.0  "--account=smanders" "--token=***" "--image-names=externpro/bldimg-x64" "--image-tags=" "--shas-to-skip=" "--tag-selection=untagged" "--keep-n-most-recent=0" "--timestamp-to-use=updated_at" "--cut-off=1m" "--dry-run=false"
thread 'main' panicked at src/client/client.rs:50:18:
Failed to fetch packages: missing field `id` at line 1 column 141

Location:
    src/client/client.rs:294:12
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

[smanders]

I've forked smanders/extenrpro to https://github.com/externpro/exdlpro

the linux clean-up job works fine there... so I suspect there's a difference running snok/container-retention-policy@v3.0.0 for a user vs an organization

I'm going to archive smanders/externpro and move forward with externpro/exdlpro until it becomes obsolete (once all the projects build their own standalone devel packages)

externpro/exdlpro will create a devel tar.xz and my plan is to download and extract it at cmake-time the same as the other devel packages... smanders/externpro expected to be installed and set-up prior to running cmake and that would require additional and unnecessary effort to get working with public GitHub runners