I wonder how this is not aligned to GitHub's roadmap.

I also cannot understand how this would be no longer relevant.

On what planet is#552 outdated?

FYI, I started a top level "Idea" discussion on#552 (threading for top level comments), see#1067

We understand you're disappointed that#552 was removed from the roadmap. We've added more detail in a comment on the issue to provide additional context. Please stay tuned for additional updates to the roadmap in coming months and continue sharing your feedback on the roadmap overhere in Community!

"Outdated for several years"

Ya'll left it sit for several years, lmfao. I don't understand this mentality of "we haven't acknowledged or addressed this issue for several years, therefore we're going to mark it as stale and close it" that most people have.

IMO#281 is better served by GitHub Actions. Implementing visual workflows would create an awkward situation where you can do things in two different ways, some features being available in the first but not in the second, and vice-versa.

This would make it frustrating to migrate from one to the other when you stumble upon missing features as well as induce decision paralysis. It would also mean less transparency to non-owner contributors of repos about the underlying workflows and prevent them from fixing them/doing a PR as needed.

@devnoname120 That's probably something worth discussing inhttps://github.com/orgs/community/discussions/53973

GitHub actions definitely offer the most flexibility, but then comes the question of where should the code live for projects that are not tied to a specific repo.

@jeherve No it's something else. Compare theschema of GitHub Workflows with theschema of GitHub Composite Actions. You will find out that there is a bunch of non-sensical[1] minute differences that makes everything unexpectedly break when you try to remove code duplication by refactoring it into GitHub Composite Actions.

[1] Non-sensical = there is absolutely no justification for the differences, they are arbitrary. For example in literally all therun steps of Composite Actions you need to writeshell: sh or... it doesn't work because this property doesn't have a default. But in Workflows thissame exact property has a default so you don't need to specifyshell: sh.

We hear your feedback and understand you're disappointed to see#281,#276, and#552 removed from the roadmap. We have added more context in comments on each of those issues, and hope you'll continue sharing your feedback on the roadmap overhere in Community. And yes,@jeherve, we love it when people upvote suggestions in the Community. :)

Myself and my organization were extremely interested in seeing#636 be implemented, as it would allow for a much tighter security posture around centralized reusable workflows. At the current moment, one must share secrets with the repository consuming the reusable workflow, which is a blatant security risk, as anyone with write access to the calling repository can then cut their own branch, modify the action file, and use the secrets however they desire. Are there any plans to implement this or similar functionality in the future?

Same here.
Had a hope we will get it.
Sad to see it is no longer in the roadmap.

Same for our Team. It would save us a lot of time and make our centralized CICD framework more secure.

This would be an incredible security boost, as it will allow to tie secrets specifically to reusable workflows (as it now is using secrets from the calling repository).

This means that if you want to reuse workflows on many repositories, you also need to make sure that secrets are available onall these repositories - and there is no way you can controlhow these secrets are being used.

It will basically allow full freedom to use any secret in any way, whereas assigning it to a centrally controller repository, you can actually control how the secrets are being used.

As an alternative, we are considering using OIDC withjob_workflow_ref to access a keyvault where the secrets are stored instead. This is quite a painful and slow workaround. It does work, but it is not ideal at all.

I would really like to see this feature in some form or another!

Thank you for sharing this feedback. We have added more detail in a comment on#636 about the removal. Stay tuned for more updates to the roadmap in the coming months and continue to share your feedback inCommunity!

GHES is cursed by not having Artifacts v4 yet and it (v3) is causing lot of noise in our developer community

v3 is one or two orders of magnitude slower at upload and download than necessary. I know because we have replaced it with Azure artifacts and Artifactory where possible (for intermediate artifacts). Still the majority of our build time is waiting until the final artifacts get uploaded…

It's ridiculous for GHES not to be kept on par with SaaS gitHub, making it harder to migrate from one to the other, and bad surprises popping up due to these inconsistencies. Differences/discrepancies between GitHub Workflows and GitHub Composite Actions are already direly painful, please don't make the situation worse by introducing additional footgun incongruences across GitHub.

If this is really intentional I am honestly considering to stop using GitHub Actions or build an own solution for artifacts. We migrated to GHA in GHES beginning this year and it has a pain ever since. We have upload and download times of up to 20-30minutes (a single large zip) with Gigabit connections, this is a pain and implies a lot of cost and risks on every build.

I really hope that it was "outdated" accidentally because they actually have no efforts internally for it and will enable usage in the next release.

Thank you for this feedback regarding Artifacts v4 in GHES. We've added more detail in a comment on#930 and continue sharing your feedback on the roadmap over in theCommunity!

Btw, discussions have reply feature.
Why not on PRs?

This is the reason issues and PRs garner 500 comments and are impossible to follow in this linear feed. GitHub massively collapsing hundreds of comments makes it even worse because you can't even search in this mess to find the information you're looking for. I've been starting to disable GitHub Issues entirely from my projects and shoehorn Discussions into a makeshift issue tracker. Very awkward.

Thank you for providing your feedback on#552 - we've added more detail in a comment on the issue. Please stay tuned for additional updates to the roadmap in coming months and continue sharing your feedback on the roadmap overhere in Community!

GitHub's merge queue is quite basic and it's meant to stay like that. They haven't invested much in it since its release last year.

Did you have a look into advanced merge queues, likeMergify? Some of them have dedicated features for monorepos.

Thanks, I'm looking into it!

Thank you for sharing your feedback. We've added additional detail in a comment on#824 and and continue sharing your feedback on the roadmap overhere in Community!

Some of these were also locked without any discussion, reasoning, or explanation.

#1014 (reply in thread)

@hyperTwitch, which?

Every single ticket I can see in this list is locked and has zero discussion, at least that the public is able to see. Just a post saying that the ticket is now "outdated" and is being closed. As you can see from the discussion here, there are more than a couple tickets on this list which the community does not understand how the feature request is "outdated".

#1014 (reply in thread)

@hyperTwitch, there is#828 (comment)... but that's about it XD

Thank you for flagging this and we understand your frustration. We have been working on adding details to the issues we've removed from the roadmap and regret not publishing that additional context to you sooner. Please check out the comments we're adding with more details on the issues you're interested in, and we're continuing to add more context and details through early December. We encourage you to continue sharing your feedback about the roadmapin this post, or feel free to open up a new thread on theCommunity with any specific questions or concerns you have!

I can only agree on this. It would have allowed us to easily enforce some rules on any new repository. That’s a shame.

We appreciate your feedback and acknowledge your disappointment with the removal of#988 from the roadmap. We've added an additional comment on the issue to provide context. Please stay tuned for additional updates to the roadmap in coming months!Join our community to continue the conversation.

Totaly agree with you
I'm starting looking Gitlab beacause of that

Please wakeup@github-product-roadmap

We hear your feedback and understand you're disappointed to see#276,#956, and#816 removed from the roadmap. We have added more context in comments on each of those issues, and hope you'll continue sharing your feedback on the roadmap overhere in Community. Stay tuned for another roadmap update in January!

We hear your feedback around#347,@hauntsaninja. We've added more context on#347 and stay tuned for more roadmap updates in the coming months.Join our community to continue the conversation.

We have hundreds of users that are refusing to use GitHub pull request reviews because of this issue. We'll definitely be raising this with our account team.

A sad day for reviews 😞.

Graphite helps

Thank you@styfle (and those replied) for sharing this feedback and we understand the disappointment around the removal of this item from the roadmap. We have added more detail in a comment on#347. Please stay tuned for more updates to the roadmap in the coming months and continue sharing your feedback on the roadmap overhere in the Community!

We appreciate your feedback and understand you're disappointed to see#347 and#552 removed from the roadmap. We've added more detail to both of those issues and will continue to update our roadmap in the coming months. Feel free to continue the conversationhere on the Community!

Thank you for sharing your feedback. We've added additional detail in a comment on#930. Feel free to continue sharing your feedback on the roadmap overhere in Community!

Thank you for sharing your feedback. We've added additional detail in a comment on#578. Jump into the communityhere to continue sharing your feedback on the roadmap.