Skip to content

Conversation

@JonoYang
Copy link
Member

@JonoYang JonoYang commented Sep 1, 2025

This PR splits the functionality of scanpipe.pipes.federatedcode.commit_and_push_changes into scanpipe.pipes.federatedcode.commit_changes and scanpipe.pipes.federatedcode.push_changes. Add scanpipe.pipes.federatedcode.write_data_as_yaml so we can write data to git repos we clone.

Copy link
Member

@AyanSinhaMahapatra AyanSinhaMahapatra left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@JonoYang LGTM, thanks I will use this also on my side as I had the same requirements of splitting commit/push and writing the purl YAML files.

@AyanSinhaMahapatra
Copy link
Member

One more thing which we need to modify/copy potentially is the check_federatedcode_eligibility function as it does a couple checks which are useful when we are pushing a scan result for a purl, but not so much for mining and writing purls:

  • all pipeline runs successful (this will not be an add-on but a standalone)
  • has a project input download URL (we might provide the index to mine from, but this could also be some hardcoded link/mentioned via settings)
  • project has a packageURL and packageurl version (also because this is not an add-on and won't have a project purl)

Should I push my commit with this on top of this branch?

One more thing potentially is we need to have a minecode_pipeline version released (using flot from something like pyproject-minecode_pipeline.toml), and install it in a branch to be able to run this from CI with SCIO github-actions from a branch (we don't need this immediately as we can just test locally, but would need this eventually)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants