Github Workflow #69
Github Workflow #69
Conversation
|
I'm going to review to the best of my abilities here. The instructions are clear and I could follow and understand them. I am still getting up to speed on github actions and am learning from reading the wiby.yaml file. So will not review that section. I did however release these changes as a module under my own organization @gvhinks/wiby so I could test with it. I could not quite work out what was required in order to trigger the wiby action. |
|
A "wiby test" comment in a PR, and then a "wiby result" comment to check for results. Less, then ideal :( but best I could come up with (and build in short time to get a PoC). |
|
I carried out a bit of experimentation by taking the changes and releasing a wiby module in a private namespace. When updating a dependency using the instructions in the PR the wiby action does the push to the dependent repo but does not get marked as completed.
|
|
If you comment "wiby result" after all the tests completed - it should go green. Do you have a link to the PR? I can take a look at the output... |
|
yes, ( apologies , work got in the way ). |
|
did as suggested ( still getting up to speed on actions ) , seemed to do the trick. |
|
Thanks for the reviews and test here @ghinks 🙇 |
|
|
||
| 0. This assumes `.wiby.json` is already configured and that you're an owner or a contributor on the dependency repo | ||
| 1. Open a PR against the dependency repository | ||
| 2. Post a comment saying `wiby test` in the PR |
There was a problem hiding this comment.
Maybe this should be a label instead? It’s cleaner and only permissioned people can do it.
There was a problem hiding this comment.
The issue with the label is that it's unclear how to re-run the job. Remove the label and add it again? Automatically remove the label on new push or when the job succeeds?
And there's still the need to wiby results... (which could alternatively be achieved with scheduled builds or smth)
Happy to iterate on this in the upcoming versions - would like to get this into some real life usage though.
There was a problem hiding this comment.
Starting the job would remove the label, so you'd just "add the label".
I also think that posting the results should be automatic, in a single updated-in-place comment, rather than requested (like codecov results, for example)
There was a problem hiding this comment.
It should be automatic, yes, but there is no simple way to achieve it with what is available. Ideally you'd be able to schedule a job or to have a sleep routine which doesn't count against your minutes, but short of that - there's a significant amount of work needed, hence why I started with a comment.
There was a problem hiding this comment.
ah, gotcha. (either way this is fine for now, just offering thoughts)
There was a problem hiding this comment.
Thanks, ideas most welcome.
|
@pkgjs/wiby-collaborators can I get some ✅ here please? |
|
🎉 This PR is included in version 0.3.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
See https://github.com/pkgjs/wiby/pull/69/files#diff-00505182d7d4129a98ee7fb7b652a1ef6b608d7620a681914db3a7a4903eee9f for usage details.
Marking this ready for review to get feedback, but we can't merge this without the following:
WIBY_TOKENI have also added a bunch of notes on #56 (comment) on how to move this forward, but I figure I'll want to make some changes to the wiby CLI first, rather than the GH actions, and I'd also like to start getting this to a more demoable place and also to start test driving this on wiby itself, even if it still requires some manual interaction (namely deleting the
wiby-wibybranch in thewiby-testorg).