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

Use Github gating (approve button) for webui-trigger workflow #6028

Closed

Conversation

jkonecny12
Copy link
Member

Currently, the webui trigger is gated for external contributors by failing the trigger workflow which demands developer to run a command on their machine to start tests on Anaconda PR.

This PR change allows external contributors execution all the time. Which raises an additional issue.

Anaconda project have workflows configured that they are required to be enabled each time manually by pressing button on the PR page. This works fine but only for pull_request trigger and webui-trigger workflow is using pull_request_target which is not covered by this gating. The pull_request_target trigger is used because we need a Github token of the workflow from the target repository so that webui tests are able to set the status on PR.

To resolve the issue above, let's use our own token instead of the workflow generated one and switch the trigger to pull_request which as side effect will also make the whole workflow more secure.

@github-actions github-actions bot added infrastructure Changes affecting mostly infrastructure f42 Fedora 42 labels Nov 28, 2024
@jkonecny12 jkonecny12 force-pushed the master-tweak-webui-trigger branch from 6e65348 to 4ddee61 Compare November 28, 2024 15:11
@jkonecny12
Copy link
Member Author

/kickstart-test --waive infra only

Copy link
Contributor

@KKoukiou KKoukiou left a comment

Choose a reason for hiding this comment

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

if you ask your brother to rebase his PR on top of this here, we can test that this works, right?

@KKoukiou
Copy link
Contributor

@jkonecny12 we need to ensure that: INSTALLER_TOKEN has write permissions for statuses (repo:status scope).

@KKoukiou
Copy link
Contributor

@jkonecny12 since you have access to the INSTALLKER token, try running the following locally; if the token a valid it will return some json, if not it will fail with bad credentials. (Replace INSTALKER_TOKEN)

 curl -X POST \
  -H "Authorization: token <INSTALLER_TOKEN>" \
  -H "Accept: application/vnd.github.v3+json" \
  https://api.github.com/repos/rhinstaller/anaconda/statuses/0bb1c33b17ecd074963821c350d2411e608ce368 \
  -d '{"state": "success", "description": "Test Status", "context": "CI/Test"}'

This is just a good practice everywhere.
Currently, the webui trigger is gated for external contributors by
failing the trigger workflow which demands developer to run a command on
their machine to start tests on Anaconda PR.

This PR change allows external contributors execution all the time.
Which raises an additional issue.

Anaconda project have workflows configured that they are required to be
enabled each time manually by pressing button on the PR page. This works
fine but only for `pull_request` trigger and webui-trigger workflow is
using `pull_request_target` which is not covered by this gating.
The `pull_request_target` trigger is used because we need a Github token
of the workflow from the target repository so that webui tests are able
to set the status on PR.

To resolve the issue above, let's use our own token instead of the
workflow generated one and switch the trigger to `pull_request` which
as side effect will also make the whole workflow more secure.
@jkonecny12
Copy link
Member Author

/packit build

@jkonecny12
Copy link
Member Author

After looking on the documentation, I found that this will not work. The issue is that pull_request trigger doesn't have access to secrets.

However, I'm thinking about hooking this workflow to another on the background. Maybe workflow run hooked on our unit tests would be a nice solution?

@jkonecny12
Copy link
Member Author

We need a different approach. Closing for now.

@jkonecny12 jkonecny12 closed this Jan 20, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
f42 Fedora 42 infrastructure Changes affecting mostly infrastructure
Development

Successfully merging this pull request may close these issues.

2 participants