You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
which would ideally require synchronization of PRs across all 3 repositories.
So I am thinking the best would be to
develop a reusable github action, which would be able to extract parameters from the PR description and expose them to the next steps in the workflow, may be even shortcutting into env vars right away.
adjust workflow here to use that github action and
if PR against bids-specification provided -- compile (into json) and use that schema
if PR against bids-examples provided -- test against those examples.
Could also allow for direct custom specification of the BIDS_SCHEMA to point to some "alternative" implementation to try.
action specification/invocation for those examples could be smth like when PR description has
### Custom settings
Lines starting with `-` would define env variables to define
- BIDS_PR=https://github.com/bids-standard/bids-specification/pull/1775
- EXAMPLES_PR=https://github.com/bids-standard/bids-examples/pull/777
- BIDS_SCHEMA=https://example.com/somewhere/schema.json
- uses: bids-standard/get-spec-from-PR-body@v1with:
section: Custom settings# optionally -- specify explicitly which to care about and error out if something else is definedenvvars: [ 'BIDS_SCHEMA' , `EXAMPLES_PR`, `BIDS_PR`]
and those envvars would be added to $GITHUB_ENV thus making them available in the next steps to potentially augment their behavior right away (e.g. as it should be with BIDS_SCHEMA I think) or to be scripted
WDYT?
The text was updated successfully, but these errors were encountered:
Relates in a spirit of improving integration between PRs to bids examples, validator and specification itself:
with a relatively simple use-case of e.g.
where we need to pair that PR with changes in a PR against validator and ensure that all is good.
And larger one could be the
which would ideally require synchronization of PRs across all 3 repositories.
So I am thinking the best would be to
Could also allow for direct custom specification of the BIDS_SCHEMA to point to some "alternative" implementation to try.
action specification/invocation for those examples could be smth like when PR description has
and those envvars would be added to
$GITHUB_ENV
thus making them available in the next steps to potentially augment their behavior right away (e.g. as it should be with BIDS_SCHEMA I think) or to be scriptedWDYT?
The text was updated successfully, but these errors were encountered: