devcontainers-community / features Goto Github PK

• Define what's eligible to be a feature #17
• Decide on what feature that could be #18 #16
• Write an install.sh script for it
• Make sure it's up-to-code and tested
• Publish it as a package manually using workflow_dispatch
• Get this feature repo added to the https://containers.dev/collections index

I think anything should not be added at this point as there are no acceptance criteria for this repository.

For example, there are clear criteria in linguist that control the language that GitHub recognizes. > We need to determine such criteria.
https://github.com/github-linguist/linguist/blob/master/CONTRIBUTING.md#adding-an-extension-to-a-language

Originally posted by @eitsupi in #16 (comment)

Here is the content of my devcontainer.json it come from here

{
    "image": "mcr.microsoft.com/devcontainers/base:debian",
    // 🧰 Add mixins and addons with devcontainer features! For a complete list
    // of features, check out containers.dev/features.
    "features": {
        "ghcr.io/devcontainers-community/features/dart-sdk": {}
    },
    // 👷‍♂️ Use 'postCreateCommand' to run commands after the container is created.
    // "postCreateCommand": "dart --version",
}

but when i reopen the current folder in a container I got this log in creation.log.

Previously, GitHub Actions gets a GITHUB_TOKEN with both read/write permissions by default whenever Actions is enabled on a repository.
As a default, this is too permissive, so to improve security we would like to change the default going forward to a read-only token. You can still flip it to read/write if needed.

This change will not impact any existing enterprises, organizations or repositories. Here is how the defaults are set going forward.

• Enterprises: New enterprises will have read-only token.
• Organizations owned by Enterprise: New organizations will inherit the permissions from parent enterprise.
• Organizations not owned by Enterprise: New organizations will have read-only token.
• Repositories owned by organization: New repositories will inherit permissions from parent organization.
• Repositories owned by personal account: New repositories will have read-only token.

— https://github.blog/changelog/2023-02-02-github-actions-updating-the-default-github_token-permissions-to-read-only/

Here's the docs on how to specify perms: https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs

• Turn on GitHub Pages from actions
• Add GitHub Action to deploy to pages
• Make the page itself

The criteria for the pages site are:

• Have an index page of all the features
• Have a unique URL for each feature
• Have pretty URLs (use name/index.html instead of name.html)
• Each individual feature page has an options table
• Each individual feature page has an example copy-paste-able
• Feat page has footer with "Feature doesn't work? Open an issue"
• Website has Troubleshooting guide page for users (NOT devs so it's not on the dev wiki)
• Feat page has footer "Need help? Find us on Gitter"

Some of these are inspired by https://github.com/devcontainers-contrib/features/discussions/290

Some options for making the website itself:

• PHP + (Wget or HTTrack)
• VuePress https://v2.vuepress.vuejs.org/guide/getting-started.html
• Eleventy https://www.11ty.dev/
• Astro https://docs.astro.build/en/getting-started/

More SSGs: https://jamstack.org/generators/

Basically the site needs to have a template for the index that for-loops through each feature as a card or similar, then have a per-feature [id].md or similar that generates a table for each feature.

@jcbhmr clean up your own mess lmao 🤣

I reset the main branch to the initial generated template commit. Why? Because I don't want to be held up on "oh but we need to wait for GitHub Pages site to work" 🤷‍♂️ so I reverted back to what works -- the PR README stuff.

I still want to do GitHub Pages SSG stuff, but that's the future. We are in the now.

So this issue is to track incorporating the following from https://github.com/devcontainers-community/features/tree/main-OLD

• Better readme
• Move .devcontainer.json to folder
• .gitattributes for .sh files
• Copy over the bash_modules prebuild.sh stuff

Depending on how devcontainers/spec#209 and devcontainers/spec#208 shake out, we might be able to ditch my bash_modules idea 🤷‍♂️ so I guess wait on that

This step is not needed.

...And, should add a step to update the website.

Keeping it private until ready for primetime. This could be a bit.