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

trigger downstream builds on issue comment #336

Closed

Conversation

pierreglaser
Copy link
Member

github workflows triggered by pull requests events actually make it clumsy to run conditional builds based on commit messages.

Alternative proposal: rely on the github IssueComment event, and run those downstream builds when a comment such as /run joblib is added in a PR.

@pierreglaser
Copy link
Member Author

/run ray

@pierreglaser
Copy link
Member Author

/run python-nightly

@pierreglaser
Copy link
Member Author

test

@ogrisel
Copy link
Contributor

ogrisel commented Feb 5, 2020

It's weird I do not see the new workflow in the actions tab: https://github.com/cloudpipe/cloudpickle/actions

@ogrisel
Copy link
Contributor

ogrisel commented Feb 5, 2020

Actually since this is not yet merged into a branch of this repo, this might be expected.

However I do not see it either on your own repo:

https://github.com/pierreglaser/cloudpickle/actions

@pierreglaser
Copy link
Member Author

pierreglaser commented Feb 5, 2020

Maybe it will show up if I open an issue/PR on my fork?

@ogrisel
Copy link
Contributor

ogrisel commented Feb 5, 2020

Alternative idea:

Put a condition on the presence of a label on the PR. We could have a new set of labels such as ci:downstream, ci:distributed, ci:nightly and based on the presence of those labels on a given PR we would run the matching CI jobs on push events to that PR.

@ogrisel
Copy link
Contributor

ogrisel commented Feb 5, 2020

Maybe if I open an issue/PR on my fork?

Yes you can try this. Maybe make a PR from a new branch that starts from downstream-builds-pr-comment into downstream-builds-pr-comment.

@ogrisel
Copy link
Contributor

ogrisel commented Feb 5, 2020

As discussed here https://gitpro.ttaallkk.topmunity/t5/GitHub-Actions/Issue-Comment-events-on-github-actions/td-p/34124 maybe the workflow is not active as long as it's not merged in the default branch of the repo (e.g. master).

Maybe you can create a new test repo (with a copy of the cloudpickle repo content) to test it and push directly to your master branch.

@pierreglaser
Copy link
Member Author

@ogrisel: I iterated on my fork, and it is now possible (on my fork) to trigger downstream builds from issue comments. I also did some extra-work so that the status of the downstream builds appear on the merge box of the PR, and not on cloudpickle's actions tab. I did this by relying on github Checks API.

I also made sure the behavior was the same whether a PR is opened from upstream (in my case, my fork) or were opened from a fork (in my case, a fork of my fork I created for the occasion :)). See pierreglaser#5 and pierreglaser#7.

It is still at a "proof of concept stage": The tests are not run (for now, nothing is done in the downstream check yet, it is simply created, and marked as successful). So i still need to plug the downstream-builds scripts into the new workflows in my fork, as well as implement at least a guard to make sure only core-devs can trigger such a build.

But I think the "hard" part, which was getting to know how to do things in github-actions, is done :)

@ogrisel
Copy link
Contributor

ogrisel commented Feb 6, 2020

Cool. Don't worry about the core dev guard. Actually I think it would be good if contributors could trigger the downstream builds by themselves on their own PR.

If it's too troublesome to adapt the build scripts to work on issue comment events instead of push events because the context is too different, maybe you could reconsider my alternative suggestion that looks simpler to implement and "good enough": #336 (comment)

@pierreglaser
Copy link
Member Author

pierreglaser commented Feb 9, 2020

Closing this as we ended up choosing another solution (#339).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants