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.

Sign up for GitHub

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

Jump to bottom

Github Workflow #69

Merged
merged 6 commits into from
Feb 12, 2021
Merged

Github Workflow #69

Changes from 1 commit
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
4d01268
ci: wiby workflow
dominykas Nov 30, 2020
4046b13
ci: unpin request-action version
dominykas Dec 31, 2020
d1a2298
ci: refactor - extract check name
dominykas Jan 3, 2021
7a4c112
ci: document installation
dominykas Jan 3, 2021
649eb04
docs: add details on usage
dominykas Jan 27, 2021
2fee3dd
docs: clarify access requirements
dominykas Jan 27, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 12 additions & 0 deletions docs/github-workflow.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -16,3 +16,15 @@ This is a manual step, until automation is ready:
- create a new one at https://github.com/settings/tokens, required scopes: `repo:status` and `public_repo`
- the account has to have push access to the test repositories - you will probably want to fork the dependents into that account (or a separate organization)
- you may want to use a robot account which _does not have **any** merge access_, as Github does not allow restricting tokens to a subset of repositories


## Usage

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
Copy link
Member

Choose a reason for hiding this comment

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

Maybe this should be a label instead? It’s cleaner and only permissioned people can do it.

Copy link
Member Author

@dominykas dominykas Jan 27, 2021 •
edited
Loading

Choose a reason for hiding this comment

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

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.

Copy link
Member

@ljharb ljharb Jan 27, 2021 •
edited
Loading

Choose a reason for hiding this comment

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

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)

Copy link
Member Author

Choose a reason for hiding this comment

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

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.

Copy link
Member

Choose a reason for hiding this comment

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

ah, gotcha. (either way this is fine for now, just offering thoughts)

Copy link
Member Author

Choose a reason for hiding this comment

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

Thanks, ideas most welcome.

- This should kick off the test workflow and update the `package.json` of configured dependents
- Shortly after that, a `wiby` status check will have its status set to `pending`
3. Wait a reasonable amount of time for the dependents to finish their tests
4. Post a comment saying `wiby result`
- Shortly after that, the `wiby` status check will changes its status to report the results of the tests in the dependents (but it may stay pending if they're still running)