is this still maintained ?

[schmurfy]

A lot of prs are piling up and I ended up having to create a frankenstein fork including all those I need but this does not really work as a long term solution so I am wondering what is the state of this project.

[vixus0]

If it's a case of workload, I'm happy to volunteer some time to review pull requests if needed.

[rickardl]

Hi,

Would you mind letting us know, what functionality you're missing?

Disclaimer and comment regarding if the project is dead, please note these are my personal opinions, other contributors might have their own view.

Our main interest is in a stable and safe implementation of GitHub PR Resource checks, although I admit, we're lacking a little bit in the speed of our reviews, a Pull Request is not guaranteed to be integrated, for example, we chose not to integrate GitHub Application authentication, because our own application found in telia-oss/sidecred issues a scoped token, as a separate component.

Otherwise, our iteration of this would probably mirror the description you made; nobody wants a frankenstein source either, if anyone wants to contribute, you could assist in refactoring the way we perform tests, as it's become a small nightmare to effectively isolate test-cases, which is one of the reasons we've slowed down integration of new features.

But the project isn't dead, we're just a bit distracted by our daily work, my organisation is moving towards GitHub Actions and some past contributors are busy as well, it's just nature of things, we do this on our own spare time, in a pro-bono fashion.

If someone wants to pitch in and incorporate some contributions, that person should probably help us make our tests more robust, there's a lot of large organisations that depend on this solution, I personally already screwed up a bit in our last release, so I was working on reducing the over-fetching but got stuck on dynamic GraphQL queries for filtering out PR's based on labels, I haven't solved that one since it would require me to template the queries, just like the GitHub CLI does.

I also spoke to DO's contributor of the fork to see if we can merge our efforts, he's left DO now and we haven't had the chance to catch up regarding that, but if some of you are serious about taking a more active role, I'd probably request help with the above, because that's where the majority of our time is spent, making every effort to not break stuff for people.

[vixus0]

@rickardl You make some very good points around the test issues. I was similarly trying to shift more of the filtering/sorting work to the GraphQL backend but then testing things becomes pretty tricky since you're now entirely dependent on the behaviour of the backend. Trying to reimplement GitHub's API as some kind of mock doesn't seem like a great option either.

For example, I made a decent amount of progress refactoring checks using GitHub's search query, which means sorting and filtering can be moved almost entirely to the backend but I had to disable all the check tests to actually see if it worked. Now I'm not sure what the best way of testing this is.

[rickardl]

Hi @vixus0

That's exactly the kind of duality in our issues with this, there's no easy way to make the current test-bench accessible to developers, side from making a test-repo available (as we do), and having developers fork that repo, perform actions and later restore.

But that's not acceptable, although integration tests are a crucial last mile, so my train of thought it looking at integrating the changes and ideas from https://github.com/digitalocean/github-pr-resource, done by https://www.linkedin.com/in/solveproblemswithcode/ (not sure why his GitHub is not linkable, maybe he made the classic mistake of creating his GitHub under his previous employer), we talked about merging the efforts earlier (because DO's fork is now unmaintained).

I would be excited and interested in moving our integrations into more loosely coupled packages, improving and maybe using the existing client from the GitHub CLI, moving interactions and interfaces for concourse into its own packages and take a pointer from the way he integrated his test, as well as actually providing proper logs and debugging steps.

That way we can focus on the intersection between Concourse and GitHub, namely the interface of our check and out resources, where our contract to developers is defined. By making contributions safer and more isolated, perhaps we could introduce a more seamless way for people to actually isolate their contributions and make sure that we have a stable foundation.

If you're interested, we could have a chat and try to make a few suggested changes as epics in some issues, to see if the ideas stick with the rest of our community.

[vixus0]

@rickardl Ok, sounds good - let's arrange something.

[schmurfy]

@rickardl I understand and I am not asking to merge everything but currently I cannot use this resource without #240, we have around 1200 prs with only a few open and without this fix the resource simply does not work as it takes so much time even concourse give up on it xD

Another nice addition is #227 which allows changing behavior depending on labels applied for more advanced workflows.

[ctreatma]

@rickardl could you clarify your earlier comment on the support model:

But the project isn't dead, we're just a bit distracted by our daily work, my organisation is moving towards GitHub Actions and some past contributors are busy as well, it's just nature of things, we do this on our own spare time, in a pro-bono fashion.

Before your org moved towards GitHub Actions, was this resource maintained as part of the contributors' daily work, or is the move away from Concourse a driving factor in adopting a pro bono support model for this resource? Given how critical PR tracking is to folks who use Concourse, maybe we could find a way to hand this resource off to the Concourse developers for continuing development.

[rickardl]

@rickardl could you clarify your earlier comment on the support model:
....
Before your org moved towards GitHub Actions, was this resource maintained as part of the contributors' daily work, or is the move away from Concourse a driving factor in adopting a pro bono support model for this resource?

Originally this was developed jointly in my current team, but time has passed, naturally some have left and our ecosystem has changed. The current the strategy has moved to using GitHub Actions as our main CI/CD tool, to reduce the overhead of onboarding developers to two systems and free up our time making these custom integrations or employing people to maintain Concourse.

This integration stills drives some "legacy" integrations internally, but it's no longer a critical path so has obviously been reduced in priorities as our focus is on other projects, which are available through other open-source repositories. This means that this work is completely done outside of working hours, even though the companies each contributor fully supports contributing to OSS projects, it still needs to make sense for the company.

Given how critical PR tracking is to folks who use Concourse, maybe we could find a way to hand this resource off to the Concourse developers for continuing development.

I won't speak on behalf of the Concourse developers, but I don't see a benefit it adding additional work on them, after all everyone is free in making contributions to this project, the issue at hand is "naive" way our tests have been implemented, see my earlier comment.

If I had confidence in our tests and we had a good way of handling integration testing against our repositories, it would be a must simpler task to accept contributions.

[ctreatma]

Thank you for clarifying! Improving the tests to make it easier to accept contributions sounds like a good approach for unblocking some of the pending contributions here. My suggestion to start a conversation with the Concourse team comes from longer-term concerns about development and maintenance. Namely: what happens to this repo when the remaining maintainers no longer work at Telia, and/or when all remaining usage of this resource is eliminated at the company?

While anyone is free to publish their own forks to pick up the torch, that only delays the problem: as we've seen with the original jtarchie repo and the digitalocean fork of this repo, eventually the teams maintaining those forks might move on as well. If we could convince the Concourse team to provide a github PR resource just as they do the git resource, that would enable us all to continue to contribute (and fork as needed), and might provide more stability for development and maintenance.

[rickardl]

@ctreatma Just a follow-up, we've been in contact with your open-source organisation, our response is similar to the above one and we're waiting for a response if Comcast is interested in discussing the future of this project.

Let us know if there's anything we can do together to support your continued use of this resource, as we explained the project is nowhere near dead, it's just that we want to make sure our releases don't break.

[ergo]

Hello, is there any update on the subject? I don't think any PR-s are getting merged at this point. And some seem to be pretty important, like the one where Github PR-s are getting forever skipped.

[bgandon]

I would be happy to offer my help and refactor the unit tests using Ginkgo, for better clarity of those.

I understand that there are more concerns about integration tests implying actual GraphQL queries, but maybe this first work would be of help in having the code easier to maintain.

I think donating this project to the Concourse team would possibly help so that new contributors can be granted roles on the project in order to maintain it. Otherwise a fork will be necessary, as I've already done last summer with the keyvalue resource.

[vixus0]

Are we asking this resource to do too much heavy lifting? Currently it is responsible for:

• Filtering PRs.
• Fetching PR metadata (a lighter version of this resource?).
• Cloning the repo (https://github.com/concourse/git-resource).
• Commenting on the PR (https://github.com/nderjung/concourse-github-pr-comment-resource).
• Setting commit statuses (https://github.com/Pix4D/cogito).

To me, it would make sense to separate the above responsibilities into smaller resource types that could be more easily maintained. Some of them already exist.

For example, the Concourse team seems to be moving towards a pattern of provisioning a Concourse pipeline per PR using the new dynamic across step. See aoldershaw's fork and usage. A resource that focused exclusively on fetching a filtered list of PRs would be beneficial here.

[bgandon]

Hey, sorry @vixus0 I had missed your answer back then.

About the across step what you say is correct, but the Concourse team at VMware had been reduced to one single employee, and that was before VMware got acquired by Broadcom..

The pace in Concourse new versions has drastically been slowed down. As I've seen so far, the investment Broadcom puts in Concourse can only cover basic maintenance work, and the roadmap to Concourse v10 has few chances to get major step forward anytime soon.

That's why we've forked this repo with friends from the Cloud Foundry community, so that the code can be maintained (bumping dependencies and Golang versions), and new maintainers possibly onboarded.

We've integrated some contributions so far and plan to continue with features that have been contributed as PRs here. We also expect the automated test suite to be developed at some point.

Don't hesitate to give it a try and share your feedback!