Consider using Issue Forms for collections-index.yml?

[jcbhmr]

Hello! 👋

This is an idea. If this is out-of-scope or something that seems too costly to maintain, that's OK.

https://github.com/stefanbuck/ristorante
https://github.com/stefanbuck/awesome-browser-extensions-for-github
☝ basically that.

https://stefanbuck.com/blog/codeless-contributions-with-github-issue-forms

Why this would be a cool idea:

• Reduce the need to make tiny manual comments that could be done via a GitHub Action and a regex add new feature 'watchman' #159 Update collection-index.yml #226
• Make adding a new collection more user-friendly (new issue instead of fork+PR)

I am willing to contribute code to do this. ❤️

[samruddhikhandale]

Hi 👋

Thanks for sharing this with us, and being willing to contribute code ❤️ (I ordered some 🍕, it's super cool)
I liked the general idea, would be user friendly, and super convenient for folks (including reviewers). ✨

In the "order pizza" example, once I added inputs to the issue form, it opened an issue followed by a commit with the changes.

Reduce the need to make tiny manual comments that could be done via a GitHub Action and a regex #159 #226

@jcbhmr A clarifying question regarding the proposal ^,

1. Would this new flow automatically commit the changes to the _data/collection-index.yml file?
2. OR Would it open a PR, run few automatic checks, comment (if needed) and then wait for a manual approval?

[jcbhmr]

@jcbhmr A clarifying question regarding the proposal ^,

1. Would this new flow automatically commit the changes to the _data/collection-index.yml file?
2. OR Would it open a PR, run few automatic checks, comment (if needed) and then wait for a manual approval?

You choose! The point that I wanted to make with the regex thing was that you can perform fancy custom validation in addition to the basic "this is an input field; any text can go here". ex:
https://github.com/stefanbuck/ristorante/blob/main/place-order.js
https://github.com/stefanbuck/awesome-browser-extensions-for-github/blob/main/submission.js

If I were to design such a thing, I might make it so that a PR is opened by the @github-actions[bot] user according to a form like this: https://github.com/stefanbuck/awesome-browser-extensions-for-github/blob/main/submission.js

And then something like this:

const ociReference = ...;
const repoURL = ...;

if (!someDockerAPI.ociReferenceExists(ociReference)) {
  throw new Error()
}
if (!gitRepoExists(repoURL)) {
  throw new Error()
}

octokit.openPRWithContents(..., "Opening on behalf of ...")
octokit.commentOnIssue(..., "I've opened a PR for you! #123...")

[samruddhikhandale]

A clarifying question regarding the proposal ^,

1. Would this new flow automatically commit the changes to the _data/collection-index.yml file?
2. OR Would it open a PR, run few automatic checks, comment (if needed) and then wait for a manual approval?

You choose!

Would like to go with option two, as it's nice to have devcontainers/maintainers 👀 on any PR for this repo.

Your proposal sounds great, I had a chat with other devcontainers/maintainers and we are willing to accept your contributions. Thank you, again for such a wonderful community support. ✨

If I were to design such a thing, I might make it so that a PR is opened by the @github-actions[bot] user according to a form like this:

There's one tiny blocker, for the devcontainers org, we don't allow GitHub Actions/@github-actions[bot] to create or approve PRs. Hence, @github-actions[bot] won't be helpful in this case. Instead, we can use the devcontainers-bot account for this purpose. I am currently working on sorting the permissions for this new bot account.

@jcbhmr do you want to wait before I sort the bot account permissions? Without that, I don't believe you would be able to implement the proposal (as we don't want to use any personal PATs)

On a side note, we still want a GitHub Action workflow to validate the manual PRs for any changes to index file. (The validations you mentioned above, checking if the URLs exist, collection artifact is valid/pull-able, includes the devcontainer-collection file, we don't have duplicate index entries etc). @jcbhmr Hence, maybe you can start working on that if you are interested? I can help provide a validation list if that would be helpful.

Let me know how we could help you in this process.

[jcbhmr]

@samruddhikhandale heres something that i think works according to what was outlined: https://github.com/devcontainers2/collections

some notes:

• it might be worth considering splitting the collections stuff into its own repository so that this website repo doesn't become too monorepo-y with issues and actions workflows etc from something that is so different from website html codes.

• I'm currently using @jcbhmr access token instead of @devcontainers-bot. to create a new $PR_TOKEN secret it needs the issue:read pr:write perms probably a granular token scoped to that repo.

[LesterCovax]

I hope there hasn't been much work invested in the proposed changes, as I've just looked at containers.dev/collections for the first time and find it...lacking. It's a mishmash of entries with either the same vague name (e.g. devcontainer-feature-set), images that are single features with their own images already, or actually useful collections that won't be discovered due to the page presentation.

The page needs to be more dynamic. By parsing the feature sets of the collections, a user could utilize feature filters to find collections of interest (even if they are terribly named...Timmy's-Great-DevBox), while expanding each entry into a list of features, and an extended space for descriptions if the creator needs it. If someone is dead set on maintaining the status quo of a not-so-useful list, at least add in pull request hooks to check for originality in the naming, and feature sets.

[samruddhikhandale]

@jcbhmr Thanks for continuing work on this, appreciate it! Do you have any latest updates or ETA for the PR contribution? We have devcontainers/spec#405 open which might be interesting to you and these changes would definitely benefit it.

@LesterCovax Thank you for sharing your thoughts, that's really helpful. We have devcontainers/spec#405 open for feedbacks and ideas on improving the community contributions for the index. Feel free to add your thoughts there, thank you! // cc @bamurtaugh

[samruddhikhandale]

By parsing the feature sets of the collections, a user could utilize feature filters to find collections of interest (even if they are terribly named...Timmy's-Great-DevBox), while expanding each entry into a list of features, and an extended space for descriptions if the creator needs it. If someone is dead set on maintaining the status quo of a not-so-useful list, at least add in pull request hooks to check for originality in the naming, and feature sets.

@LesterCovax Have you taken a look at https://containers.dev/features (or https://containers.dev/templates)? They do provide a list of Features which are contributed by the community and directs to the source repository. I understand that we are missing a search bar, but you can currently find a list of all Features. Let us know if I have misunderstood your question, thanks!

[bamurtaugh]

Thanks again all for the great discussion and feedback here! I've opened a PR to tackle the issue form + automation aspect: #354. Please feel free to check it out and provide any feedback/questions/recommendations!

[bamurtaugh]

We additionally have a PR in progress for adding search: #325.