Per-project show SCIO commit used

[AyanSinhaMahapatra]

Currently we show the current SCIO commit deployed for the instance (with the SCIO and SCTK versions), but we also show old SCIO projects which were started on different states of SCIO, and sometimes even in the same project, we can have different pipeline runs which were started on different states of the SCIO instance (i.e. different commits deployed in the SCIO instance). We should ideally:

• include the SCIO commit used in the pipeline log

And also as enhancements we can (but these would be too much maybe?):

• have some warning/note text in the pipeline log UI which indicates that these pipelines were run on different commits than the current one
• have commit hashes for each pipeline displayed in the UI (and maybe have links to github diffs to see the exact changes in SCIO for these?)

This would be helpful because we can look at the exact changes in SCIO between two projects/pipeline runs from the exact SCIO commits used to run the pipeline and would help debug bugs/issues.

What do you think @pombredanne @tdruez

[tdruez]

include the SCIO commit used in the pipeline log and maybe have links to github diffs to see the exact changes in SCIO for these

Added in https://github.com/nexB/scancode.io/pull/965

The Run.scancodeio_version is now displayed in the pipeline run modal:

When possible, this value is displayed as a link to the GitHub diff view with the current ScanCode.io app version.

---

have some warning/note text in the pipeline log UI which indicates that these pipelines were run on different commits than the current one

We already have something similar, displaying a warning in the Project details view:

The implementation at https://github.com/nexB/scancode.io/blob/main/scanpipe/views.py#L606 is not ideal though as it is based on a fixed version_limit. We should instead base this global warning on a more generic version limit, maybe based on the minor, or major release in the version. Displaying this warning on a simple version diff would be too aggressive. Also, we could add a similar logic to the pipeline log UI as you suggested.