Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[Feature]: Discussion: How should we make the scripts to run python-only integration test script drivers available through CLI

Aperta
  • Qualcosa non va?
#12 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
32/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Tranquilla
Stack tecnologico
python, shell
Ambito
build-system, cli, testing-qa

Direzione di ricerca

Inizia esaminando la struttura di scripts/ del repository e pyproject.toml, quindi confronta il file esistente drunc_integtest_bundle.sh con gli entry point installati da Spack. Determina quale approccio di packaging è adatto ai repository Python-only e verificalo in un ambiente CVMFS nightly generato. Il lavoro è completo quando il comando del bundle dei test di integrazione è disponibile senza una copia locale del repository.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement help wanted python
Description

For this example I will use drunc to describe the workflow, as there are already established integration tests available.

Generally, we will want to be able to run integration test scripts as e.g.

drunc_integtest_bundle.sh

For Spack-deployed repositories, using daqsystemtest as an example, we have the following contents in the $PATH environment variable

printenv PATH | tr ":" "\n" | grep daqsystemtest
/cvmfs/dunedaq-development.opensciencegrid.org/nightly/NFD_DEV_260728_A9/spack-0.22.0/opt/spack/linux-almalinux9-x86_64/gcc-14.3.0/daqsystemtest-NFD_DEV_260728_A9-kv4363vbd354ams7ykhehizrqy32ab4v/bin

which contains the following executables

ls /cvmfs/dunedaq-development.opensciencegrid.org/nightly/NFD_DEV_260728_A9/spack-0.22.0/opt/spack/linux-almalinux9-x86_64/gcc-14.3.0/daqsystemtest-NFD_DEV_260728_A9-kv4363vbd354ams7ykhehizrqy32ab4v/bin
check_example_configs.sh  daqsystemtest_integtest_bundle.sh  dst_get_pytest_tmpdir  dunedaq_integtest_bundle.sh  list_available_integtests.sh  list_repos_with_integtests.sh

This deployment model has not currently been established for the python-only repository structure. A plan needs to be formed for how to make the script executable without a local instance of this.

Potential impact radius

Small/Isolated

Reason for change

Currently to run drunc_integtest_bundle.sh, one has to have a local copy installed, but we want to make this executable if the repository is distributed through CVMFS.

Suggested implementations

The optimal solution would be have a strategy for including the scripts/ path of these repositories as a direct parallel to that of the Spack distributed repositories. This is something I am not currently familiar with, and would like to continue with.

A different solution would be to define the entry point for operating these scripts as a repository entry point, e.g. adding the following to the pyproject.toml

[project.scripts]
<repo_name>_integtest_bundle = '<repo_name>.apps.<repo_name>_integ_tests:main'

and having this script execute the shell script defined in <repo_name>/scripts/<repo_name>_integtest_bundle.sh. An extension to this could be to have the command implemented directly in the script. I have a preference for hadnling the entry points to the integration test bundle driver scripts the same as for Spack-deployed repositories to minimise differences between the repository structures.

Testing suggestions

Generate a nightly environment once the changes have been implemented, and check whether the entry point is available without having a local copy of the relevant repository.

Anything else?

N/A.

Lingua principale
Python
Stelle
0
Fork
0
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

  • Nessun Dockerfile né file Docker Compose
  • Ha un modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di DUNE-DAQ/daqpyutils

Tutte le issue di DUNE-DAQ/daqpyutils

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.