Create devcontainer.json

[arifinahmad99-cloud]

Commit Message Guidelines
Basic Structure
():

Commit Types

feat: A new feature
fix: A bug fix
docs: Documentation only changes
style: Changes that don't affect code meaning (formatting, semicolons, etc.)
refactor: Code changes that neither fix bugs nor add features
perf: Code changes that improve performance
test: Adding or updating tests
chore: Build process, dependencies, or tooling changes
ci: CI/CD configuration changes

Writing Rules
Subject Line

Use imperative mood ("add" not "added" or "adds")
Don't capitalize the first letter
No period at the end
Limit to 50 characters
Be specific and descriptive

Body

Explain what and why, not how
Wrap at 72 characters
Separate from subject with a blank line
Use bullet points for multiple changes

Footer

Reference issues: Closes #123, Fixes #456
Breaking changes: BREAKING CHANGE: description

Examples
Good Commit Messages
feat(auth): add two-factor authentication

Add TOTP-based two-factor authentication for user accounts. Users can enable 2FA in their security settings and will be prompted during login.

Closes #234
fix(api): prevent race condition in user updates

The concurrent updates to the same user document could cause data loss. Added pessimistic locking to ensure sequential writes.

Fixes #789
refactor(components): simplify button styling

Extract common button styles into a shared utility class. Reduces CSS duplication by 40 lines.
Bad Commit Messages
updated stuff
fixed things
WIP
asdf
changes
Quick Reference
DoDon'tfeat: add user authenticationFeature: user authenticationfix: correct typo in email validationfixed bugUse imperative moodUse past tenseLimit subject to 50 charsWrite long subjectsExplain reasoning in bodyLeave body emptyReference issuesNo issue tracking Common Patterns
Feature with related tasks:
feat(dashboard): add analytics widgets

• Add revenue chart component
• Add user growth metric
• Add performance metrics card

Closes #345
Bug fix with explanation:
fix(form): handle special characters in inputs

Special characters were causing form validation to fail. Updated the regex pattern to properly escape these characters.

Fixes #567
Refactoring:
refactor(utils): consolidate date formatting functions

Merged dateFormat and formatDate into single utility. Improved consistency and reduced code duplication.
Tips for Great Commits

Commit frequently and logically—each commit should represent one change Don't mix unrelated changes in a single commit
Write the message as if completing: "This commit will _____" Avoid generic messages like "update" or "fix"
Use the present tense consistently
Keep commits atomic—they should be reversible independently

Pre-requisites

• Prior to submitting a new workflow, please apply to join the GitHub Technology Partner Program: partner.github.com/apply.

---

Please note that at this time we are only accepting new starter workflows for Code Scanning. Updates to existing starter workflows are fine.

---

Tasks

For all workflows, the workflow:

• Should be contained in a .yml file with the language or platform as its filename, in lower, kebab-cased format (for example, docker-image.yml). Special characters should be removed or replaced with words as appropriate (for example, "dotnet" instead of ".NET").
• Should use sentence case for the names of workflows and steps (for example, "Run tests").
• Should be named only by the name of the language or platform (for example, "Go", not "Go CI" or "Go Build").
• Should include comments in the workflow for any parts that are not obvious or could use clarification.
• Should specify least privileged permissions for GITHUB_TOKEN so that the workflow runs successfully.

For CI workflows, the workflow:

• Should be preserved under the ci directory.
• Should include a matching ci/properties/*.properties.json file (for example, ci/properties/docker-publish.properties.json).
• Should run on push to branches: [ $default-branch ] and pull_request to branches: [ $default-branch ].
• Packaging workflows should run on release with types: [ created ].
• Publishing workflows should have a filename that is the name of the language or platform, in lower case, followed by "-publish" (for example, docker-publish.yml).

For Code Scanning workflows, the workflow:

• Should be preserved under the code-scanning directory.
• Should include a matching code-scanning/properties/*.properties.json file (for example, code-scanning/properties/codeql.properties.json), with properties set as follows:
  • name: Name of the Code Scanning integration.
  • creator: Name of the organization/user producing the Code Scanning integration.
  • description: Short description of the Code Scanning integration.
  • categories: Array of languages supported by the Code Scanning integration.
  • iconName: Name of the SVG logo representing the Code Scanning integration. This SVG logo must be present in the icons directory.
• Should run on push to branches: [ $default-branch, $protected-branches ] and pull_request to branches: [ $default-branch ]. We also recommend a schedule trigger of cron: $cron-weekly (for example, codeql.yml).

Some general notes:

• This workflow must only use actions that are produced by GitHub, in the actions organization, or
• This workflow must only use actions that are produced by the language or ecosystem that the workflow supports. These actions must be published to the GitHub Marketplace. We require that these actions be referenced using the full 40 character hash of the action's commit instead of a tag. Additionally, workflows must include the following comment at the top of the workflow file:

  # This workflow uses actions that are not certified by GitHub.
  # They are provided by a third-party and are governed by
  # separate terms of service, privacy policy, and support
  # documentation.
  

• Automation and CI workflows should not send data to any 3rd party service except for the purposes of installing dependencies.
• Automation and CI workflows cannot be dependent on a paid service or product.