create github actions for tool

[macblazer]

Do you have a public example of a repo using this GitHub Action?

[fnxpt]

Hi,

As far as I know putting it on .github/actions doesnt make this a public action, if you look at their own examples like this they have the action.yaml on the root directory. Regarding the path parameter, this is the path for the source directory, the location where you have your Podfile.

Additionally this page says that it needs to be on the root directory.

[macblazer]

Hi,

As far as I know putting it on .github/actions doesnt make this a public action, if you look at their own examples like this they have the action.yaml on the root directory. Regarding the path parameter, this is the path for the source directory, the location where you have your Podfile.

Additionally this page says that it needs to be on the root directory.

Good point. I read this part but skipped the first sentence of that paragraph that shows it only for "..an action that you don't plan to make available to others..."

If you plan to combine action, workflow, and application code in a single repository, we recommend storing actions in the .github directory. For example, .github/actions/action-a and .github/actions/action-b.

[fnxpt]

Ok cool, are you ok with the current code? On the second link I put the wrong page - https://docs.github.com/en/actions/creating-actions/publishing-actions-in-github-marketplace If you are ok, when you do a release you can publish it to marketplace

[macblazer]

The only thing I'm wondering about is whether to use the ruby code right from this repo to do a

gem build cyclonedx-cocoapods.gemspec
gem install cyclonedx-cocoapods-x.x.x.gem

(with the correct version number in there) in the action instead of installing a released gem from RubyGems as the current action.yml does. If we can do the gem build; gem install of the local code that would tie the action.yml more closely to the current codebase. As additional parameters are added to the CLI code, the action.yml can be updated with additional inputs to match and the release process updates everything at once.

The inputs.version would not be needed then, and instead consumers would use the uses: clause of their action to import the version of cyclonedx-cocoapods that they want to use.

We will need to probably set up a v1 tag so consumers of the action can point at cyclonedx-cocoapods@v1 like other actions do. Then we can move that tag as future releases are made.

[fnxpt]

I see a couple of issues with that. You will need to checkout the code in order to build it (remember this action will run on the other repo not this one) Building a gem takes time and this means more execution time on the workflow and also more credits spent if you are running this inside a private repo. Regarding the version, we can force latest but I think this way it's more flexible if someone wants to use a specific version.

[macblazer]

After consulting with other CycloneDX Maintainers, for consistency with other CycloneDX projects we created a new repository for the Github Action here

https://github.com/CycloneDX/gh-cocoapods-generate-sbom

Please submit this action and associated README changes to that project instead of having it here with the ruby code.

[fnxpt]

Created a new PR https://github.com/CycloneDX/gh-cocoapods-generate-sbom/pull/2