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

require condalock action to run successfully before allowing merge #48

Open
JessicaS11 opened this issue Mar 21, 2023 · 2 comments
Open
Labels
type: enhancement An improvement of some kind.

Comments

@JessicaS11
Copy link
Contributor

The condalock action fails silently, so if a test is fixed to pass, the PR checks pass and allow merging even if the conda-lock.yml has not been updated. The /condalock action must be re-triggered to run, and should be required to pass before merging is allowed.

@weiji14 weiji14 added the type: enhancement An improvement of some kind. label Mar 21, 2023
@weiji14
Copy link
Member

weiji14 commented Mar 21, 2023

Thanks @JessicaS11 for opening this issue and adding the note at c65efc7 about checking the Actions tab. I'm hoping that turning the /condalock into a standalone command (#18) would allow us to enable this check under the 'Checks' tab of a PR, rather than someone having to jump to the Actions tab.

In the meantime, this 'check' will unfortunately need to fall on the Pull Request reviewer 🙂

@weiji14
Copy link
Member

weiji14 commented Sep 20, 2023

From what I can tell after working a bit on #88, it won't be possible to enable a check under the 'Checks' tab with a slash command like /condalock because it uses workflow_dispatch or issue_comment triggers.

Instead, we would need to use either the pull_request, pull_request_target, or pull_request_review target (similar to the UML diagram update check on icepyx in icesat2py/icepyx#208). How about we forego having to write /condalock directly, and just use a pull_request_target based GitHub Action workflow to automatically regenerate lockfiles (when certain files like environment.yml has changed)? This would be similar to how some automatic linters work, and means that we can see what is happening in the 'Checks' tab instead of having to manually go over to the 'Actions' tab to see whether the lockfile has been re-generated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: enhancement An improvement of some kind.
Projects
None yet
Development

No branches or pull requests

2 participants