As lukascbossert already pointed out, one aspect of reproducibility is the understanding of what you have done.
First, let me state:
When trying to reproduce something, you should aim to fully automatize your workflow.
Second:
Stick to the KISS principle.
Some questions arise:
- What is your "workflow"?
- Of what kind are the results, you want to reproduce?
- Do the software versions play a meaningful role?
- Does hardware play a role?
- Do you have special requirements in terms of needed programs, packages, CPU-/GPU-power or enormous amounts of data?
- What other tools are already in place? Is your workflow already/can be scripted with some stable tool like bash-shell (KISS)?
- What is the desired level and ease of reproducibility?
Bitwise reproducibilty is nearly(?) impossible. - How much time&effort are you willing to invest?
- Are you aiming to reproduce results in future (e.g. 10 years)?
- Do you use third-party/closed source software? Do you need licenses (could you need them in future?)? Will you always be able to go back to a certain software version?
One way to approach your problem (based on some assumptions on the answers to the previous questions) would be:
- Automate your workflow.
- Build a container (e.g. docker/apptainer) with your workflow in it.
- Test it does work with GitLab/GitHub CI or on another machine.
- Archive and link to each other:
- your (documented) code,
- results & intermediary results
- your image file (apptainer) or upload to dockerhub
- (related scientific paper)
Possibly you could also take a look into dedicated workflow tools like snakemake, but I am no expert in that. My group does not use is, because it is yet-another-tool and not needed in our work ->KISS.