Comments (9)
OK, I think this issue is on the critical path - the CLI approach is all nice, but wiby
needs to happen in CI.
I tentatively opened this referencing Github Actions, but actions don't make this easy, so I'll need to do some digging.
Kicking off the initial wiby test
is the easy part.
The hard part is to collect the results, because you can't trigger an action off a status change in another repo. Which means some sort of polling, but there's no obvious way of implementing that using actions either, or at least no obvious way which wouldn't use up the precious actions minutes.
There could be a scheduled which basically polls all the things that are in flight, but I'm struggling to imagine a way to make it easy to set up, as GH actions don't have a way of sharing workflows.
Neither is this easy on Travis - you'd essentially have to keep a job running until it times out or the dependents finish their jobs, which can be rather wasteful as well.
I'll ponder other available tools to achieve this, but ideas are most welcome!
from wiby.
OK, so here's the plan:
- For the initial version, there will not be an automated results check. I don't have a good solution to save on minutes. So you will have to use a comment to
wiby test
, which will kick off the tests, and it will also set a status check to pending. You will then have to explicitly comment towiby result
, which will loop through the tests that were kicked off and update the status check accordingly.- I will open an issue on GH side to add a "sleep" step (which wouldn't count against minutes) or to add a "delayed trigger" (which would explicitly kick off X minutes after Y event or X minutes after an explicit API call).
- There will be several GH workflows involved, so I'll add a new command to sync up the canonical workflows. Not sure about the combo of commands - an interactive
wiby install
would be awesome, but this also needs a silent way to just update the options. Maybe awiby outdated
andwiby update
make sense. I'm thinking to do this as part ofwiby
, but it probably makes sense to extract as a separate package as well, if the approach proves itself viable.
from wiby.
Things not covered in #69, to be reconsidered if we want them for MVP:
- It seems the the
details_url
does not do what I want it to do... Basically, the status check under the PR links to the details about the status check, but somehow does not want to link to the actual build details. - Ideally, we should report detailed results (the markdown that we now have) as a comment. We should think wether we should keep one comment per PR and update it with details, or whether we should just post a new comment after every
wiby results
run. (I do hate thewiby results
comment pattern... but don't have any better ideas right now, that I can also implement fast, and not waste build minutes) - The GH API seems to indicate there is some sort of a "Require action" button functionality - maybe it is possible to use that instead of the
wiby results
comment? - Can labels be better triggers than
wiby test
/wiby result
comments? - Right now, the branch that
wiby
pushes to is based on the dependency name. We should do better than that and instead use the branch name of the dependency somewhere in there. This would allow linking multiple dependencies into one, e.g. you're testingdep-one
anddep-two
insideuser-of-one-and-two
. Bothdep-one
anddep-two
have a new feature developed on a branch namedfeat/new-stuff
. Runningwiby test
indep-one
would create awiby-feat-new-stuff
branch withdep-one
linked intouser-of-one-and-two
. Runningwiby test
indep-two
afterwards should see thatwiby-feat-new-stuff
already exists and linkdep-two
, while keepingdep-one
linked.- We should probably also always rebase on top of the default branch, i.e. if the branch exists, we should fetch the package.json, detect wiby-linked packages, and then apply that on top of master as well as the new changes.
- Improve status check reporting to set the "Pending" status immediately and have a separate status for
wiby results
check (indicating that the results check has completed). - Add some code to install/update the GH workflow code in the repositories where it is used.
from wiby.
i am very interested in this “require action” functionality, and have never come across it before.
from wiby.
https://docs.github.com/en/rest/reference/checks - look for action_required
- the docs weren't super clear to me and I haven't had time to experiment with this just yet... And then there's a mention of actions
which allows "a button on GitHub that can be clicked to alert your app to do additional tasks", but it is unclear to me if you have to have an app or this is achievable for the workflows.
from wiby.
ah, that reads to me as just a way to indicate to github that the user has to click the "details" link, and do something else. visual diffing uses this, for example, to force users to go click a button confirming that yes, this visual change was intended.
from wiby.
Yeah, quite likely, although if that can be wired up to kicking off another job - that's all that's necessary. Or a readme telling to post a comment 🤷♂️
from wiby.
Looks like Github only sets the COLLABORATOR
relationship if you're added to the repo directly (seems like a known issue), but it does not create it when you're added via team (or by being an org admin). This means that the permission check for the comment is probably rather inefficient...
I guess we'll need to rewrite the comment trigger to instead be a label... which can kind of work for kicking off the wiby test
(the job should probably remove the label when the test ends), but there's still a need for a trigger to check wiby result
and I see no trivial solution (which does not waste minutes) to achieve this.
One option is to have a label for wiby in progress
. The collaborator of the repo would then remove the label to check for results. If the tests are still in progress - the job would add the label back, or something. Not a pretty flow, if you ask me... Comments are nicer :(
I guess I could rework this to check the permissions via the API, even if it would cost some actions seconds...
🤔
from wiby.
OK, the known issue with collaborators is still there, and it is a rather annoying one to work around, so I guess I'll try to reimplement the workflow with labels. Here's what I'm thinking right now:
- Someone opens a PR
- A collaborator adds a
wiby test
label - This triggers the
wiby
workflow:- it checks the wiby status on the commit - it is missing, so it sets it to pending
- it removes the
wiby test
label from the PR- it should maybe add the
wiby in progress
label instead, just to make this status visible the PR list?
- it should maybe add the
- it kicks off the
wiby test
command
- (time passes)
- A collaborator looks at the PR and re-adds the
wiby test
label - This triggers the
wiby
workflow again:- it checks the wiby status on the commit and sees it is pending
- it removes the
wiby test
label from the PR - it kicks off the
wiby results
command - if the results are in - it sets the
wiby
status to red or green on the commit - if the results are still pending - it keeps the pending status
Gotchas:
- This has much less extensibility than the comment option, unfortunately, but at least it's simple enough?
- Suppose the
wiby
status is pending, and downstream dependent builds are stuck for whatever reason - how does one kick off thewiby test
again? I'm trying to avoid multiple different labels (i.e. I don't want a separatewiby retest
or awiby check results
label).
Next steps:
- A nightly scheduled action, which scans all open PRs, checks their
wiby
status and wherever it is pending - adds thewiby test
label to kick off thewiby results
workflow
from wiby.
Related Issues (20)
- Dependency Dashboard
- Reference the fork when running from a PR from a forked repository
- Github Workflow: trigger a retest
- Rebase forks before testing
- Support testing devDependecies (et al) HOT 4
- Pretty print results HOT 7
- Switch coding style HOT 7
- Add support info HOT 1
- semantic-release bot is quite noisy HOT 4
- Description of what Wiby does and how it achieves this needs improvement HOT 5
- default branch master => main HOT 3
- Action Required: Fix Renovate Configuration
- Name wiby test branches based on the dependency branch name
- `wiby clean` command HOT 3
- Link the current branch/commit, rather than default branch HOT 1
- Investigate repository_dispatch HOT 2
- Tests on main are failing HOT 4
- Existing branch handling HOT 3
- Github Workflow: cleanup when parent PR is closed
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from wiby.