Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix GH actions to work on forks! #402

Open
alexsnaps opened this issue Dec 10, 2024 · 3 comments · May be fixed by #405
Open

Fix GH actions to work on forks! #402

alexsnaps opened this issue Dec 10, 2024 · 3 comments · May be fixed by #405
Labels
github_actions Pull requests that update GitHub Actions code

Comments

@alexsnaps
Copy link
Member

Our actions are currently broken. I'm unsure to what extent, but at least the FOSSA one still is, despite me trying to get it working.
See here for the latest type of failure. I reverted that, but now that means that again, on forks and PR of forks, that step will be broken!

I don't know whether its the action itself, or what it is... but this whole secrets stuff is broken beyond belief! It was a mistake to put all this config stuff in the repo alongside the code, blame GH... but what can we do? Should we move all our CI out of this mess? I've searched, but can't seem to find what are the proper patterns to support this fork contribution workflow, which... is actually how GH is supposed to work, but... not GH actions? What am I missing?

@alexsnaps alexsnaps moved this to Todo in Kuadrant Dec 10, 2024
@alexsnaps alexsnaps added the github_actions Pull requests that update GitHub Actions code label Dec 10, 2024
@eguzki
Copy link
Contributor

eguzki commented Dec 10, 2024

On other repos, the fork contribution workflow is supported disabling all actions where permissions are required. For instance, push a docker image to the registry. See example: https://github.com/Kuadrant/limitador-operator/blob/main/.github/workflows/build-images-for-tag-release.yaml#L174

if: github.repository_owner == 'kuadrant'

Why do you need to test if some secret is nil additionally? Is it not enough to test repository owner? Or even github.repository == 'Kuadrant/limitador' LGTM as well.

@alexsnaps
Copy link
Member Author

Why do you need to test if some secret is nil additionally?

Don't focus on that... it doesn't even fix the issue... for some reason the github.repository check still has this action break for... some reason. It worked out ok for all other actions, but not the FOSSA one... I don't know why and also don't know, as this issue tries to convey, what is the proper way of addressing these problems... But they keep on coming back, despite the multiple changes, and break forks, which I don't think is desirable.

@eguzki
Copy link
Contributor

eguzki commented Dec 11, 2024

I used github context dump step to see the value of github.repository when the PR comes from a fork.

- name: Dump GitHub context
  env:
    GITHUB_CONTEXT: ${{ toJson(github) }}
  run: echo "$GITHUB_CONTEXT"

It turns out that github.repository attribute value is Kuadrant/limitador even for forked PR's. See this run.

If I am not mistaken on your goal, the way to achieve that is like this for jobs being run on pull requests

if: github.event.pull_request.head.repo.full_name == github.repository

Fossa license scan job is the only one job that runs when PR's are open with a guard like if: github.repository == 'Kuadrant/limitador'. The other jobs with such a guard are only executed when something is merged on main or being tagged.

@eguzki eguzki linked a pull request Dec 11, 2024 that will close this issue
@eguzki eguzki linked a pull request Dec 11, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
github_actions Pull requests that update GitHub Actions code
Projects
Status: Todo
Development

Successfully merging a pull request may close this issue.

2 participants