Use Acts from Github, bump version

This switched the remote to the Github repo at https://github.com/acts-project/acts, and bumps the tag to v0.22.0. I'm trying to force a clean checkout. In my tests, no changes where required in Athena master.

Changes since v0.18.00 are:

v0.19.00

Bug

• !782 - Abort propagation when an interaction kills a particle

Improvement

• !792 - Bump required boost version to 1.69
• !791 - Include momentum in error estimation of the EigenStepper
• !784 - Seedfinder test: specify input file on command line, quiet output
• !783 - Allow partial event simulation in case of errors
• !777 - Promote Polyhedron to Surface base class

Uncategorized

• !787 - Remove redundant geometrySignature

4 issues addressed in this release:

Bug

• #697 - Abort condition from the physics lists are ignored

Improvement

• #709 - Remove redundant geometrySignature
• #716 - Allow partial event simulation in case of errors
• #705 - Use Polyhedron representation for Geometry building

v0.20.00

Bug

• !797 - Workaround for is_invokable problem
• !795 - Vertexing: AMVF bug fix

Improvement

• !804 - Consistent storage and access schema for bounds - part 2
• !799 - Remove printout from Propagation Integration test
• !798 - Use DDCore target directly
• !789 - Consistent storage and access schema for bounds
• !785 - Clean up the parameter definitions

Infrastructure

• !801 - Allow overriding clang-format binary with an env var
• !800 - Set up Github Actions jobs to run checks and builds

Uncategorized

• !802 - Remove propagator options from vertexing configs and performance upgrades
• !796 - Add code style/ naming guidelines

3 issues addressed in this release:

Bug

• #718 - Free parameters are missing an enum detailing its content.

Improvement

• #719 - Consistent storage and access schema for bounds

Uncategorized

• #722 - Add code style/ naming guidelines

v0.21.00

Improvement:

• Visualization geometry #91
• Visualization surfaces #84
• Miscellaneous AtlasStepper and EigenStepper fixes, AtlasStepper docs #85
• Create CODE_OF_CONDUCT.md #81
• Move Visualization into separate folder #80
• Add AMVF unit test for user-defined track type #75
• Contributions update #66
• Removing clone functionality #72
• Add badges to readme #70
• Add missing acts namespace in AnnealingUtility #68

Infrastructure

• Add config for W I P app #89
• Attempt to fix codecov configuration #87
• Add config for new bots #65
• Run coverage job on master and PR to master #69
• Add codecov tolerance threshold of 0.1% #79

v0.22.00

Improvement:

• Merge impact point estimators #106
• Have CTest display test output if a test fails #105
• Gaussian vertex seedfinder cleanup and performance updates #101
• Record volume material in the Interactor #92
• Move StandardAborters, Debugger out of detail #98

Bug Fixes:

• Fix access stereo variable in DiscTrapezoidBounds #108

changed the description

AE Build SUCCESS
Build logfiles are available at Jenkins [AE-MERGE-REQUEST-CC7 #235]

merged

mentioned in commit 20321d9b

This one has an interesting side effect. Some of our external builds (e.g. athena!32376 (closed)) are now failing with:

13:28:31 error: pathspec 'v0.22.00' did not match any file(s) known to git.
13:28:31 CMake Error at /build2/ci-builds/master/Athena/build/AthenaExternals/tmp/Acts-gitupdate.cmake:144 (message):
13:28:31   Failed to checkout tag: 'v0.22.00'

The reason is that on that build node, still the old repository is configured:

[aibuild16-018] /build2/ci-builds/master/Athena/build/AthenaExternals/src/Acts > git remote -v
origin  https://gitlab.cern.ch/acts/acts-core.git (fetch)
origin  https://gitlab.cern.ch/acts/acts-core.git (push)

I am slightly puzzled why our weekend cleanup of the build nodes didn't take care of that. This will need manual intervention by Alex. Until that's done to avoid further failures, @pagessin, would it be possible to bring the ATLAS repository in sync with github?

You mean the repository at https://gitlab.cern.ch/acts/acts-core.git? We intentionally tried to make that read-only, but I can manually sync it right now.

I didn't quite realise that !660 (7d3ec289) would not correctly re-clone the repository. I really thought that it would...

And I agree, the weekend cleanup should really have taken care of it. I'm pretty confused why it didn't...

Indeed, the clone should never have worked (tried it locally). Moreover the source directory is being deleted before the clone:

/build2/ci-builds/master/Athena/build/AthenaExternals/tmp/Acts-gitclone.cmake:

execute_process(
  COMMAND ${CMAKE_COMMAND} -E remove_directory "/build2/ci-builds/master/Athena/build/AthenaExternals/src/Acts"

But that makes it even more mysterious...

I thought that would be taken care of by the forced redownload. I'm not sure what's happening either.

Ok I pushed v0.22.00 to the gitlab instance now, which should be an immediate fix for the build failures I hope.

Thanks @pagessin. That should give us some more time to figure out what's going on here.

@akraszna looking at BuildLogs/Acts.log on aibuild16-018, I see in fact two clone commands:

# CMake ---> /cvmfs/atlas.cern.ch/repo/ATLASLocalRootBase/x86_64/Cmake/3.16.4/Linux-x86_64/bin/cmake -P /build2/ci-builds/master/Athena/build/AthenaExternals/tmp/Acts-gitclone.cmake
Cloning into 'Acts'...
Note: checking out 'v0.22.00'.
[...]
# CMake ---> /cvmfs/atlas.cern.ch/repo/ATLASLocalRootBase/x86_64/Cmake/3.16.4/Linux-x86_64/bin/cmake -P /build2/ci-builds/master/Athena/build/AthenaExternals/tmp/Acts-gitclone.cmake
Cloning into 'Acts'...
Note: checking out 'v0.07.02'.

The first one works just fine, but it's the second one that I think is using the wrong repository. Looking on another node (aibuild16-020) where the build works, I don't see this second clone.

Since we have no idea what's going on, I asked Alex to clean aibuild16-018.

mentioned in merge request athena!32440 (merged)

The disk of aibuild16-018 is now cleaned. The problem was caused by git hiccup as I mentioned on mattermost ( https://atlas-sit-ci.cern.ch/job/CI-MERGE-REQUEST-CC7/13077/console ). Then jobs against master were broken on this machine, but jobs against 21.2 were OK, and therefore the problems were not so conspicuous (when the problem occurs for all jobs on the particular machine Jenkins usually continues to schedule next jobs on exactly the failed machine and then it is very conspicuous - all jobs in the queue just fail momentarily)