CI: LTS container workflow overwrites develop Intel latest image and breaks PEXSI builds

[Stardust0831]

Problem

The LTS and develop branches can both publish their Intel container to the same mutable tag:

ghcr.io/deepmodeling/abacus-intel:latest

The two branches have different Dockerfile.intel contents. In particular, the LTS image does not install/export PEXSI, while the develop Build Test workflow enables ENABLE_PEXSI=ON and now requires PEXSIConfig.cmake through config-mode package discovery.

As a result, an unrelated push to LTS can overwrite the image used by develop and PR CI, causing deterministic CMake configuration failures.

Observed timeline

1. The Intel extra-components job in run 30995571234 succeeded at 09:59 UTC on 2026-08-05.
   • Pulled abacus-intel:latest digest: sha256:c38db3f67dfc412e9b929d9323d2660f4acc3976071b60cb005cb8ca1d02aaf4
   • Compiler: IntelLLVM 2025.2.1
   • Image exported the PEXSI-related environment.
2. LTS Container run 30994242030, triggered by unrelated commit 4fd5f19, pushed a new Intel image to the same latest tag at 10:15 UTC.
   • Published digest: sha256:815bcab0722b3345a356edc83e67d33ced0d1ea56bc0304d866577d642a7d327
   • Image metadata revision: 4fd5f19ac50d66c9d8ec3f526ead53d646281ede
3. The next Intel extra-components job in run 30998345926 pulled that new digest and failed.
   • Compiler changed to IntelLLVM 2026.1.1.
   • CMake could not find PEXSIConfig.cmake or pexsi-config.cmake.
4. The same failure occurred in run 31001027794, while all other Build Test matrix jobs passed.

The failing source commits did not modify the container, toolchain, or PEXSI configuration.

Root cause

PR #6210 added LTS to the Container workflow trigger, but both branches continued publishing the raw latest tag. PR #7615 later changed develop to require PEXSI's config package, making the LTS image incompatible with the develop Intel extra-components job.

This is a container tag collision and reproducibility problem, not a hardware failure.

Suggested fix

1. Ensure only develop publishes latest.
2. Publish LTS images under a separate tag such as lts-latest.
3. Apply the workflow correction to the LTS branch itself, because Actions uses the workflow file from the pushed branch.
4. Rebuild the develop Intel image after preventing the LTS overwrite, restoring a PEXSI-capable latest image.
5. Consider using an immutable digest or a develop-specific immutable tag in build_test_cmake.yml so CI cannot change underneath an unrelated run.

For example:

tags: |
  type=semver,pattern={{version}},enable=${{ github.ref_type == 'tag' }}
  type=raw,value=latest,enable=${{ github.ref == 'refs/heads/develop' }}
  type=raw,value=lts-latest,enable=${{ github.ref == 'refs/heads/LTS' }}

Acceptance criteria

• An LTS push does not change ghcr.io/deepmodeling/abacus-intel:latest.
• LTS publishes to a distinct tag.
• The develop Intel extra-components job can find PEXSIConfig.cmake and configure successfully.
• The image reference used by Build Test is reproducible or branch-isolated.

[Growl1234]

One possible solution is to append branch name to the name of containers and docker packages, which will 100% avoid this undesired case.

[Stardust0831]

@Growl1234 I prepared #7781 following the branch-specific package-name approach. The PR moves LTS publication and its BuildKit cache to abacus-{gnu,intel,cuda}-lts:latest in both registries, while intentionally preserving the existing unsuffixed abacus-*:latest names for develop and legacy consumers. This prevents future LTS pushes from overwriting develop images without requiring an immediate migration of existing workflows or user scripts. After it is merged, the develop Container workflow will still need to be rerun once to restore the currently overwritten unsuffixed latest images.