-
Notifications
You must be signed in to change notification settings - Fork 129
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
Fix CI #484
Fix CI #484
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for working on this!
I think I want to move the unmaintained plugins into a section called "Unmaintained". "Archive" doesn't really seem like the right place for plugins that we want to remove from testing but may become maintained again, once the maintainers return.
From @cdecker :
No, I think we should a) ping authors when things break, b) exclude from testing if it doesn't get fixed in a timely manner (it is distracting for other plugin devs), followed by c) archival (move it out of the main directly) and finally d) deletion if there is no volunteer to maintain the plugin.
I think of us as repo maintainers, not plugin maintainers. Our job is to guide others through the process of developing and publishing their plugin, ensuring quality standards and safety concerns are addressed, but we aren't the ones responsible for addressing them. Does that make sense?
So, I think the best strategy is to move the plugins into "Unmaintained" for now, and create a new section on the README that identifies these plugins.
At the same time we can ping the plugin maintainers to update their plugins, and hopefully they will return.
@fmhoeger another thing, can you revert the changes I made to the demoted plugins? It will be disorienting for maintainers when they come back to fix their plugins and the code has changed. |
Pull request has been modified.
I added some commits in a PR here https://github.com/fmhoeger/plugins/pull/1 is that a good way to contribute? |
@daywalker90 yes, this is very helpful, thanks!! Let's add that in as a separate PR, because the focus of this PR is just to get the CI up and running again. New features should go in separately. |
@fmhoeger this is great! Unfortunately it looks like someone has updated |
…te GitHub action versions
…t, probe, prometheus, rebalance, and summary to the archive drain: fix drain msats drain: failing CI because of msats historian: add inotify to historian deps historian: update lockfile
Remove bitcoind-version 22.0 from matrix
Add new section Unmaintained plugins Cleanup and sort plugin and link lists
@chrisguida OK, rebased just now. Will check if the tests pass for |
@chrisguida Tests for |
Ok, thanks! Also, can you please move "unmaintained" back to "archived"? I'm just realizing that "archived" and "unmaintained" appear to be the same thing cf96eb6#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5L182 Otherwise, can you just make |
We could add back this note as well: cf96eb6#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5L184-L186 |
Update text and links for archived plugins in README
@cdecker this is ready to go. For the merge, should we do:
? |
Oh hmm, I guess mergify merged it after my approval.... whoops @cdecker let us know if you want us to clean up the commit history on master |
:D |
@chrisguida The workflow badge still shows failing, even though the last master run was green. Maybe the badge should be changed, not shure though: #489 |
What good should I do to get back the |
@gallizoltan Just submit a PR that takes it out of archived and fixes the tests such that it passes CI, like this PR: #495 |
This PR makes the CI tests pass again.
archived
subdirectory. These are:autopilot
,backup
,commando
,donations
,drain
,feeadjuster
,helpme
,historian
,jitrebalance
,noise
,paytest
,probe
,prometheus
,rebalance
,summary
.CLN_VERSION
to 23.11.2bitcoind-version
26.0 to matrixcln-version
v23.11 and master branch to matrixDEVELOPER
env var