hemmelig: Add version 1.0.0

[ltguillaume]

Adds Hemmelig CLI v1.0.0 https://github.com/HemmeligOrg/Hemmelig.app/releases/tag/cli-v1.0.0

• [x] Use conventional PR title: <manifest-name[@version]|chore>: <general summary of the pull request>
• [x] I have read the Contributing Guide

Summary by CodeRabbit

• Chores
  • Added a Windows distribution manifest to enable official Windows installs and automatic updates via GitHub releases, including versioned downloads and integrity checks.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai[bot]]

Walkthrough

Adds a new Windows package manifest file bucket/hemmelig.json containing metadata, download URL and SHA256, executable details, and GitHub-based autoupdate configuration for Hemmelig.

Changes

Cohort / File(s)	Summary
Package manifest bucket/hemmelig.json	New Windows package manifest JSON: version, description, homepage, license, architecture-specific download URL and SHA256, binary name, GitHub releases-based version check and autoupdate template.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

• Validate JSON syntax
• Verify download URL(s) and SHA256 hash
• Confirm GitHub release tag and autoupdate substitution pattern

Poem

🐰 A tiny manifest tucked in a file,
Hemmelig leaps across each download mile,
JSON neat, a package trail,
GitHub sings the update tale,
Hop—distribution done with a smile. 🥕📦

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title 'hemmelig: Add version 1.0.0' clearly summarizes the main change—adding a new package manifest for Hemmelig version 1.0.0, and follows the conventional format specified in the template.
Description check	✅ Passed	The description provides a brief summary of the change (adding Hemmelig CLI v1.0.0) with a reference to the release, and both required checklist items are marked as completed, indicating the author followed the repository's contributing guidelines.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

🧪 Generate unit tests (beta)

• [ ] Create PR with unit tests
• [ ] Post copyable unit tests in a comment

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between fb384ce0337a04e0fbf8e4006c22444a1e36d5e7 and 220d5302fec9c586766cb25d66f191f34977a6ca.

📒 Files selected for processing (1)

• bucket/hemmelig.json (1 hunks)

🚧 Files skipped from review as they are similar to previous changes (1)

• bucket/hemmelig.json

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: WindowsPowerShell

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[github-actions[bot]]

All changes look good.

Wait for review from human collaborators.

hemmelig

• [x] Lint
• [x] Description
• [x] License
• [x] Hashes
• [x] Checkver
• [x] Autoupdate

Check the full log for details.

[z-Fng]

PRs labeled package-request-needed are less likely to be reviewed and may be closed if there are no updates for a long time.

Please create a package request before submitting a PR to add a new package to this bucket. When creating a package request, you can check the criteria for a package to be accepted in this bucket, which can help you determine whether your PR is likely to be approved. The information provided in the issue can also help maintainers quickly get the necessary details.

Extra manifests for Scoop, the Windows command-line installer. For manifests that don't fit the Main criteria.

For a package to be acceptable in this bucket, it should be:

1. Reasonably well-known and widely used. e.g. if it's a GitHub project, it should have at least 100 stars and/or 50 forks *
2. English interface (or at least English documentation) *
3. Latest stable version *
4. Full version (i.e. not a trial version)
5. Fairly standard install (e.g. uses a version-specific download URL, no elaborate pre/post install scripts)

[ltguillaume]

Done: #16759

I have made the request in Extras, not Main, because the (only) criterium it does not meet is that it's not a developer tool (in the narrowest sense of the word).

[aliesbelik]

/verify

[github-actions[bot]]

All changes look good.

Wait for review from human collaborators.

hemmelig

• [x] Lint
• [x] Description
• [x] License
• [x] Hashes
• [x] Checkver
• [x] Autoupdate
• [x] Autoupdate Hash Extraction

Check the full log for details.

[ltguillaume]

@aliesbelik I'm trying to understand the changes made:

1. The license is probably because it's not (yet) a "default" license type, I guess?
2. The architecture wrapper, I can understand. Using just url: seems perfectly valid, since there is only one architecture available, but it wouldn't communicate to Scoop which architecture is available.
3. Is there any particular reason to use the repository ID instead of its name? Using the ID is less transparent and if the repo is ever renamed, GitHub should just redirect without any issues.
4. The hash seems superfluous to me, because AFAIK Scoop will still calculate and include it in the manifest without it.

[aliesbelik]

1. The license is probably because it's not (yet) a "default" license type, I guess?
2. The architecture wrapper, I can understand. Using just url: seems perfectly valid, since there is only one architecture available, but it wouldn't communicate to Scoop which architecture is available.

Exactly. For details you could use manifest properties description.

3. Is there any particular reason to use the repository ID instead of its name? Using the ID is less transparent and if the repo is ever renamed, GitHub should just redirect without any issues.

Redirect works for the repo GH link but not for the API endpoint (wonder if it was already changed/fixed): https://github.com/ScoopInstaller/Main/pull/5215#issuecomment-1778915170.

4. The hash seems superfluous to me, because AFAIK Scoop will still calculate and include it in the manifest without it.

Adding hash to autoupdate. First autoupdate.hash section (if specified), then github-generated digests for release assets (if available), only then - downloading file(s) and calculating hash(es).

[ltguillaume]

@aliesbelik Thanks for taking the time for explaining this. I'll go over my own bucket and see if it needs adjustments and I'll make sure to implement this in any future PRs.