DCO Expected — Waiting for status to be reported
vasukulkarni opened this issue · comments
Is there an issue with DCO bot? It seems to be stuck forever in our PR checks?
Example PR: red-hat-storage/ocs-ci#4578
We were experiencing similar issues in the fluxcd organisation, e.g. fluxcd/website#580 - we just had to disable the check.
Same issue for the keptn organization (e.g. keptn/keptn#5612)
Same issue for the cortexproject/cortex (e.g. cortexproject/cortex#4525). Does anyone know how to fix it (we would like to keep it enabled)?
We are also encountering this problem at kumahq/kuma
We are encountering the same problems with https://github.com/com-pas/compas-cim-mapping/
I'm afraid nobody is maintaining DCO for a while now. I've been asking for someone else to step up and take on ownership/maintainership. It looks like GitHub is shutting off servers for probot apps now.
I'd recommend you deploy your own instances until a new maintainer is found.
I think servers got turned back on, but only for another grace period of 4 weeks.
If nobody steps up and offers to take on ownership this app and repository will be shut down for good then.
@gr2m Do we need to rerun the existing pipelines or this will pick all the pending jobs?
@gr2m are you able to clarify, are servers being shut off for probot apps in general, or just for apps that don't currently have maintainers?
@gr2m, What is the process to take over the ownership? My company, i am working at, can do this, if its okay? We use the DCO too in our OSS projects.
@gr2m are you able to clarify, are servers being shut off for probot apps in general, or just for apps that don't currently have maintainers?
In general.
The only app in the @probot org that has a maintainer is the settings app. We will move https://github.com/probot/settings/ out of the @probot org and deploy it to servers not owned by GitHub.
@gr2m, What is the process to take over the ownership? My company, i am working at, can do this, if its okay? We use the DCO too in our OSS projects.
I don't think there is a process, so we can make it up as we go. I'll try to have someone from GitHub reach out, thank you for offering!
Ok @gr2m, please let me know. You can reach out via Github or Twitter to me. Or we can quickly make a zoom/slack/teams call if you want.
Hi, @gr2m , I work for The Linux Foundation and we would be very interested in helping with ownership/maintenance
Because several people asked me, here is what I would suggest we do for the transition:
- Create an announcement discussion or pinned issue to announce the transition of ownership of the app
- Link to the discussion/issue from the top of the app repository's README
- Add a new permission to the app, any permission will do. This will trigger a notification to all installations. Requesting a new permission can include a short message in which I'd link to above issue/discussion
If you want to (or have to) enforce that someone reads and accepts the change of ownership, we could add a check to the app that makes sure that only installations that have the new permission continue to work.
Maybe there is a better process, I'd be curious if there is some kind of precedent. But that's what I'd do given what is possible today.
@karasowles will get a call set up with @ryjones and @rginn to figure this out and then we can document the plan in this repo.
I am very disheartened to see GitHub abandon running these apps, especially so suddenly and without any warning. I think that was a horribly unfair move @github. I don't have interest in continuing to maintain this project longterm, but I will step in to help if needed to transfer app/repo ownership.
@gr2m proposal is a great one (transferring the app to a new owner). One alternative I'll throw out there would be to just start fresh with a new app. By that I mean have the Linux Foundation move this repo somewhere they own, and create and host a new app. This would mean the following
- Someone would need to create a new App (new App ID, private key, etc.) - it would need to be named slightly differently
- Host it somewhere
- Everyone currently using would need to install the app again
- Everyone uninstalls the old app
This way there is no code change/check required to ensure folks are consenting to the new owners, and that way the folks running the app can directly manage it and utilize things like error logs to make improvements. Maybe re-installing the app everywhere is too much work, but considering org level installs, it's possible it might be simpler.
For everyone's reference if creating a new App is something you all might consider, here's the current config for the app:
Maybe re-installing the app everywhere is too much work, but considering org level installs, it's possible it might be simpler.
We are also facing this issue for our project.
Hi, audiences in this thread,
I'm facing this issue yesterday and write an "action" with the inspiration of this project. You can check it out:
I hope with GitHub hosted runner we don't meet this maintenance issue any longer.
Of course, you can deploy your own DCO App instance. Here is just one more alternative. I search on the marketplace but no existing actions work as well as DCO App, either too complex or depending on other things.
Under the Keptn github organization I also created a DCO check pipeline that can be directly used through this GH feature
Link to the pipeline: https://github.com/keptn/gh-automation/blob/main/.github/workflows/dco.yml
An example usage of this pipeline:
name: DCO
on:
pull_request:
push:
branches:
- "master"
jobs:
check:
uses: keptn/gh-automation/.github/workflows/dco.yml@v1GitHub
This repo is the single source of truth for pipelines that are shared across Keptn repos - gh-automation/dco.yml at main · keptn/gh-automation
@mowies I found dco-check also and it's great to solve the problem. I just notice that it write thousands lines of code with multiple config options which probot/dco impl doesn't have and thus I write my own in about 100 lines.
There is more than one way to do it :)
@karasowles will get a call set up with @ryjones and @rginn to figure this out and then we can document the plan in this repo.
Hi @martinwoodward @ryjones just checking in. Did you guys meet? Do you have any updates? LMK if I can help.
Hi @mynameistechno - we had a very productive chat last week, and are confident about where we're headed, but we need to work a few more details out before we have an actual update. Sorry about the delay here, we want to get it right this time around. The app is back online and we're sorting out what happened on our side for it to go offline.
@mynameistechno I had a talk last week with @ashleywolf - things are moving
At OpenSTEF we experienced the same problem, disabled the DCO check (for now).
can you share the exact pull request where the problem occurred?
I was not able to reproduce a problem in my test repository: gr2m/sandbox#218
Hi, it appears that this issue has re-appeared for checks on May 6th between the hours of 10:00 -16:00 GMT. Multiple repos and orgs have stalled checks in their PRs during this time, but new PRs made after this time period successfully run.