Deal with old Github runs

[elisabettai]

It looks like that GitHub CI runs disappear after a while.

E.g. I had a repo with the last commit from June 2022 (484 days ago), which had no CI runs associate to it anymore.
This fails with:

$ 'git ls-remote https://github.com/ITISFoundation/spinal-cord-toolbox.git refs/heads/main -q'
==================================================
GENERATED PIPELINE
==================================================
stages:
    - info
no-further-action-required:
    image: $CI_SERVICE_INTEGRATION_LIBRARY
    tags:
    stage: info
    tags:
        - DOCKER
        - XSERVER
        - GPU
        - LINUX
    script:
        - echo "Nothing required updates. No builds scheduled."
==================================================
Traceback (most recent call last):
  File "/.pyenv/versions/3.10.10/bin/dpos", line 33, in <module>
    sys.exit(load_entry_point('docker-publisher-osparc-services==0.0.1', 'console_scripts', 'dpos')())
  File "/.pyenv/versions/3.10.10/lib/python3.10/site-packages/click/core.py", line 1157, in __call__
    return self.main(*args, **kwargs)
  File "/.pyenv/versions/3.10.10/lib/python3.10/site-packages/click/core.py", line 1078, in main
    rv = self.invoke(ctx)
  File "/.pyenv/versions/3.10.10/lib/python3.10/site-packages/click/core.py", line 1434, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/.pyenv/versions/3.10.10/lib/python3.10/site-packages/click/core.py", line 783, in invoke
    return __callback(*args, **kwargs)
  File "/.pyenv/versions/3.10.10/lib/python3.10/site-packages/docker_publisher_osparc_services/cli.py", line 130, in main
    asyncio.get_event_loop().run_until_complete(run_command(config))
  File "/.pyenv/versions/3.10.10/lib/python3.10/asyncio/base_events.py", line 649, in run_until_complete
    return future.result()
  File "/.pyenv/versions/3.10.10/lib/python3.10/site-packages/docker_publisher_osparc_services/cli.py", line 38, in run_command
    if not await did_ci_pass(repo_model, branch_hash):
  File "/.pyenv/versions/3.10.10/lib/python3.10/site-packages/docker_publisher_osparc_services/operations.py", line 47, in did_ci_pass
    return await github_did_last_repo_run_pass(repo_model, branch_hash)
  File "/.pyenv/versions/3.10.10/lib/python3.10/site-packages/docker_publisher_osparc_services/http_interface.py", line 31, in github_did_last_repo_run_pass
    raise Exception(f"Could not find associated run to commit {branch_hash}")
Exception: Could not find associated run to commit ca7b4a14eff6c188e786ca4ec6b2a4b68bcdad32

And it might happen again.
Workarounds exist, so it is not very urgent.

Workaround

Trigger a pipeline run in the concerned repository (e.g. just edit the README.md directly in the main/master branch) or any other file that is not ignored and that triggers a CI run. The Ci doesn't need to be "green" at the end.

[GitHK]

fixed in v1.0.4 by 90cf8a4

[GitHK]

Above fixed a different issue, related to pagination.

[elisabettai]

This occurred again to @Konohana0608 and @wvangeit and it will happen again, since CI runs on Github are deleted after 90 days.

@pcrespov, @sanderegg, as a Owner of IT'IS Foundation, I just noticed that we can increase CI logs and artifacts retention time to 400 days. Do you have anything against increasing from the current 90 days?

[pcrespov]

@GitHK This happened again during the weekend. Thx for having a look at it.

[GitHK]

@pcrespov @bisgaard-itis You have removed a core feature. How will you now detect and fix failing pipelines in time?
This has to come back from my point of view. You should have just commented the block of code responsible for checking that repository in the configuration if you cannot fix it.

[GitHK]

For future reference

This is an intentional feature designed to monitor failing CIs, enabling us to periodically rebuild Docker images. Without this, rebuilding Docker images after several years could become extremely problematic.
Although it may seem inconvenient, this approach helps spread out the effort required to rebuild images with unpinned dependencies over time.
Typically, the issue can be resolved by simply restarting the CI.

[GitHK]

I will revert the above PR and make the error message a bit more obvious to the actions needed to be taken when it presents itself again.