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

PR preview not building for members without write access #121

Closed
ccarouge opened this issue Oct 4, 2022 · 3 comments · Fixed by #122 or #126
Closed

PR preview not building for members without write access #121

ccarouge opened this issue Oct 4, 2022 · 3 comments · Fixed by #122 or #126
Assignees
Labels
🪲 bug / mistake Something isn't working, is misplaced, or misspelt

Comments

@ccarouge
Copy link
Contributor

ccarouge commented Oct 4, 2022

The action to deploy github pages only works for people with write access to the repository.

It seems there is an option to configure Git to a specific user which we could use so all PR are built from the same GitHub user account with writing access to the repository.

@ccarouge ccarouge self-assigned this Oct 4, 2022
@ccarouge ccarouge added the 🪲 bug / mistake Something isn't working, is misplaced, or misspelt label Oct 4, 2022
@ccarouge
Copy link
Contributor Author

ccarouge commented Oct 4, 2022

The action we are using is not set to work in this case. Some changes are in the works: rossjrw/pr-preview-action#3 but the changes are not yet ready for use.

@ccarouge ccarouge changed the title PR preview not building for members without writing access PR preview not building for members without write access Oct 4, 2022
@ccarouge
Copy link
Contributor Author

ccarouge commented Oct 4, 2022

There are a few options here:

  1. give write access to all the organisation's members. Downside: requires a good vetting system of who becomes a member, any member could then create a repository in this organisation. Changes proposed by non-members would not have a preview.
  2. leave it as is and remove the possibility to have a preview from the PR for people without write access. Downside: it can be hard to review changes correctly without a preview.
  3. change the CI to be triggered on pull_request_target instead but only on PR with a specific label. Only people with write access can add a label to a PR. It would mean the label is typically added at the time of review. Downside: once the label is added, the originator of the PR can push any commit they want to their branch and have them run in the CI.
  4. Use a 2 steps CI following what is proposed here. Downside: it is a lot more work and requires us to maintain the GitHub action ourselves.

@ccarouge
Copy link
Contributor Author

ccarouge commented Oct 4, 2022

For the now, we will go with the 3rd option above for ACCESS-Hive. We'll investigate the 4th option over the longer term.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🪲 bug / mistake Something isn't working, is misplaced, or misspelt
Projects
None yet
1 participant