Determine best way to include composite actions

[onedr0p]

Currently we use hardcoded repo paths onedr0p/containers/.github/workflows/simple-checks.yaml@main in certian steps, it would be great to figure out how to make that more generic for people who are forking this repo and want to build their own containers.

[br3ndonland]

The easiest thing to do would be to change the reusable workflow references to local reusable workflows. It looks like you're already using local references for the render-readme workflow.

containers/.github/workflows/release-on-merge.yaml

Lines 37 to 42 in 9ee194d

	render-readme:
	name: Render Readme
	needs: build-images
	if: ${{ always() && needs.build-images.result != 'failure' }}
	uses: ./.github/workflows/render-readme.yaml
	secrets: inherit

Happy to get you a PR to update the other ones if it's helpful.

Composite actions are a bit different. You'd have to convert the reusable workflows to action.yml files, and they have a bunch of quirks and restrictions (like this). In general I'd recommend sticking with reusable workflows instead of composite actions.

Thanks for maintaining this project. Lots of useful container images.

[onedr0p]

There was an issue with using local reusable workflows and I honestly can't recall what it was, maybe @JJGadgets or @bjw-s remember 😄

[onedr0p]

I found the previous discussion on it here

#918 (comment)

[br3ndonland]

I found the previous discussion on it here

#918 (comment)

I don't agree with that comment. PRs can always run "with a modified version of the workflow." Any other PR could make the same change shown in #918 (comment) and Actions would run that change. I don't think the uses: key is really the primary security measure. Other security measures available for PRs:

• Repos have a setting for preventing GitHub Actions from creating or approving pull requests
• GITHUB_TOKEN only has read permissions on PRs from forks
• GitHub secrets don't get passed to workflows that run on PRs from forks
• If there are further security restrictions needed, secrets can be added to deployment environments that require approvals or only run on certain refs

[bjw-s]

Any other PR could make the same change shown in #918 (comment) and Actions would run that change.

At the time that we were building this workflow system, I believe we tested this and it would ever only run the workflow contents from the main branch even if the PR specified something else, making this the "easiest" way to do this at the time. Of course insights evolve and we should iterate on / revisit previous results so if there are better ways to do these things today we should definitely take a look at them (when time permits)