search

InsightSoftwareConsortium / ITKRemoteModuleBuildTestPackageAction

A composite GitHub Action to build, test, and package, ITK remote modules
Apache License 2.0
3 stars 6 forks source link

DOC: Add documentation for community contributions #51

Closed tbirdso closed 1 year ago

tbirdso commented 1 year ago

Closes #47

tbirdso commented 1 year ago

@jhlegarreta Thanks for the revisions!

Can you please add a self-contained description of the contribution in the commit message, body? It helps a lot instead of just saying "Closes #N".

Typically I add a longer commit message, but this PR is limited in scope and therefore the title "Add documentation for community contributions" fully sums up changes.

jhlegarreta commented 1 year ago

Typically I add a longer commit message, but this PR is limited in scope and therefore the title "Add documentation for community contributions" fully sums up changes.

IMO minimally C&P'ing the subject in these cases is still helpful/conveys the idea of a complete commit message. But anyways.

dzenanz commented 1 year ago

@tbirdso if a remote module requires some non-standard build dependency (e.g. presence of Perl, or building of specialized library X), it still cannot use this action? It needs to use the old-style code, like in https://github.com/InsightSoftwareConsortium/ITKIOOMEZarrNGFF/blob/5fd54c1099eb44d5d5fb29eb349003b4cb651255/.github/workflows/build-test-package.yml#L39-L40? Is this correct? I really wish they allowed inclusion of yaml files, as per https://github.com/actions/starter-workflows/issues/245.

tbirdso commented 1 year ago

if a remote module requires some non-standard build dependency (e.g. presence of Perl, or building of specialized library X), it still cannot use this action? It needs to use the old-style code, like in https://github.com/InsightSoftwareConsortium/ITKIOOMEZarrNGFF/blob/5fd54c1099eb44d5d5fb29eb349003b4cb651255/.github/workflows/build-test-package.yml#L39-L40? Is this correct? I really wish they allowed inclusion of yaml files, as per https://github.com/actions/starter-workflows/issues/245.

@dzenanz Unfortunately yes, to the best of my knowledge there is not currently a good path to allowing remote modules to inject additional environment setup steps on a case-by-case basis. Some modules may be able to work around this by fetching and installing dependencies as part of CMake config, such as how ITKElastix pulls and builds Elastix in its CMakeLists.txt. For other modules such as IOOMEZarrNGFF it seems like the only path forward for now is to maintain the workflow fork and manually apply incremental updates to mirror the ITKRemoteModuleBuildTestPackageAction commit history as needed.

The issue you linked and its related anchors issue seem like they would present a path forward if implemented, but it looks like the issue hasn't been a priority for the GitHub team over the past couple of years. Open to revisiting if that or another path are made available.

jhlegarreta commented 1 year ago

https://github.com/InsightSoftwareConsortium/ITKRemoteModuleBuildTestPackageAction/pull/51#issuecomment-1376038053 If a "sufficient" number of modules need a given library L, I guess a boolean flag could be added to the workflow. It is somehow suggested in the text Tom proposes that such a feature could be accepted. Not sure how many would be "sufficient". And if they require library L but versions V1 vs V2, we would hit a difficulty there.