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

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

Summary by CodeRabbit

• Chores
  • Added a Windows distribution manifest to enable official Windows installs and automatic updates from releases, with versioned downloads and integrity checks to ensure safe, updatable installations.

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

[coderabbitai]

Walkthrough

Adds a new Windows package manifest bucket/hemmelig.json with metadata, versioning, 64-bit artifact URL and SHA256, executable name, and GitHub releases-based checkver/autoupdate configuration.

Changes

Cohort / File(s)	Summary
Package manifest bucket/hemmelig.json	New Windows package manifest JSON: name, version, description, homepage, license, x64 download URL and SHA256, executable (Hemmelig.exe), checkver using GitHub release tags, and autoupdate URL/hash templating.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

• Validate JSON syntax and schema
• Verify download URL and SHA256
• Confirm GitHub release tag regex and autoupdate template

Suggested reviewers

• aliesbelik
• z-Fng

Poem

🐰 A tiny manifest tucked in a file,
Hemmelig hops to every GitHub mile,
JSON neat, a download paved,
Versioned tags and hashes saved,
Hop—updates arrive 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 and specifically summarizes the main change: adding a new package manifest for Hemmelig CLI version 1.0.0. It follows the conventional PR title format requested in the template.
Description check	✅ Passed	The PR description includes the required conventional PR title checklist item (marked complete), confirms reading the Contributing Guide, and provides a relevant release link. However, it lacks a specific issue reference (Closes/Relates to #XXXX) as shown in the template.
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: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 220d530 and 274a69d.

📒 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]

All changes look good.

Wait for review from human collaborators.

hemmelig

• Lint
• Description
• License
• Hashes
• Checkver
• 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).

[bjarneo]

Edit: sorry, I thought I was on another repo 😅 Can't delete the comment

[aliesbelik]

/verify

[github-actions]

All changes look good.

Wait for review from human collaborators.

hemmelig

• Lint
• Description
• License
• Hashes
• Checkver
• Autoupdate
• 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): ScoopInstaller/Main#5215 (comment).

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.

[z-Fng]

Thanks for your contribution!

The manifest will update automatically as the package updates, as long as the upstream releases new packages that follow the same pattern defined in the manifest. If there are any other changes, feel free to submit a PR.

[z-Fng]

Redirect works for the repo GH link but not for the API endpoint (wonder if it was already changed/fixed): ScoopInstaller/Main#5215 (comment).

It looks like redirects work for the GitHub API as well now.
e.g.,

• http://api.github.com/repos/th-ch/youtube-music/releases/latest
• http://api.github.com/repos/pear-devs/pear-desktop/releases/latest

[ltguillaume]

Redirect works for the repo GH link but not for the API endpoint (wonder if it was already changed/fixed): ScoopInstaller/Main#5215 (comment).

It looks like redirects work for the GitHub API as well now. e.g.,

Good to know! Personally, I think using the repo ID is less user friendly/transparent, so I'd opt for changing this policy in Scoop manifests.

[z-Fng]

Exactly. I'm also wondering if we can use the repo name directly in the GitHub API now, instead of the repository ID. It would be much more intuitive. We could even go a step further and use CI to fix/correct the repo links.

[ltguillaume]

Related to this PR, I've also been looking into how to deprecate the manifest in my own bucket, ideally making it "transition" to using the Extras bucket. I can't find anything actionable about this in the documentation, other than that I can move my manifest into the deprecated folder and Scoop will notify the user only if they manually check via scoop status or scoop list. There is no warning during an update and as far as I can see, no update will be performed if another bucket does supply an update for the same package if the bucket of origin has deprecated the package (of course this can cause issues).

1. Would there be a notification if there's a new version in the Extras manifest, even if it was originally installed from another bucket? (I'm afraid not)
2. I'm guessing the only way to transition to the Extras bucket is to uninstall, then reinstall, or to change the bucket in apps\hemmelig\install.json?

I'm asking because this may always happen, in any bucket, without the user really noticing.

[z-Fng]

1. Would there be a notification if there's a new version in the Extras manifest, even if it was originally installed from another bucket? (I'm afraid not)

No, there won't be.

2. I'm guessing the only way to transition to the Extras bucket is to uninstall, then reinstall, or to change the bucket in apps\hemmelig\install.json?

Exactly. We are lacking the mechanisms to remove or replace a manifest now. See: ScoopInstaller/Main#7524 (comment) As a workaround, we typically add a deprecation notice to the existing manifest and then deprecate it in a few months. e.g., #17040

[ltguillaume]

Got it. Maybe the smallest change to really improve things would be to list deprecated packages (just like with status) on every scoop update underneath the commits listing. It would at least alert users properly, because status and list simply won't be triggered (regularly) by most users.