{"id":22599623,"url":"https://github.com/singularityhub/singularity-deploy","last_synced_at":"2025-06-27T01:32:42.010Z","repository":{"id":40411538,"uuid":"355347619","full_name":"singularityhub/singularity-deploy","owner":"singularityhub","description":"Build and deploy Singularity containers to GitHub releases, and pull with the singularity-hpc client","archived":false,"fork":false,"pushed_at":"2023-10-12T12:30:09.000Z","size":79,"stargazers_count":17,"open_issues_count":3,"forks_count":12,"subscribers_count":5,"default_branch":"main","last_synced_at":"2025-06-10T13:49:24.759Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"Singularity","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mpl-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/singularityhub.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":".github/FUNDING.yml","license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null},"funding":{"github":"vsoch"}},"created_at":"2021-04-06T22:39:10.000Z","updated_at":"2025-05-16T19:34:23.000Z","dependencies_parsed_at":"2025-03-28T19:47:24.697Z","dependency_job_id":"630bd4fe-9304-41ce-a907-912fb1ffd268","html_url":"https://github.com/singularityhub/singularity-deploy","commit_stats":null,"previous_names":[],"tags_count":3,"template":true,"template_full_name":null,"purl":"pkg:github/singularityhub/singularity-deploy","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/singularityhub%2Fsingularity-deploy","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/singularityhub%2Fsingularity-deploy/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/singularityhub%2Fsingularity-deploy/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/singularityhub%2Fsingularity-deploy/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/singularityhub","download_url":"https://codeload.github.com/singularityhub/singularity-deploy/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/singularityhub%2Fsingularity-deploy/sbom","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":262172641,"owners_count":23270066,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-12-08T11:10:44.771Z","updated_at":"2025-06-27T01:32:41.652Z","avatar_url":"https://github.com/singularityhub.png","language":"Singularity","funding_links":["https://github.com/sponsors/vsoch"],"categories":[],"sub_categories":[],"readme":"# Singularity Deploy\n\n![img/shpc.png](img/shpc.png)\n\nWouldn't it be nice to build Singularity images without a registry proper,\nand just keep them alongside the GitHub codebase? This is now possible!\nThis small repository provides an example to get you started. It will\nbuild one or more images (whatever Singularity.* files that are present at\nthe root) and then release them as assets to your GitHub repository so\nthat they can be programatically obtained. It is associated with \n[singularity-hpc](https://github.com/singularityhub/singularity-hpc) to allow\nyou to then define LMOD modules for these same containers. \n\n\u003e Can I upload the largest of chonkers?\n\nYes and no. Note that assets are limited to 2 GB in size, which is still fairly good. You can use\nit as a template for your own recipes as is, or modify it for your custom\nuse case. Instructions are below!\n\n**Note** Currently recipe extensions are associated with tags, and the GitHub release is\nassociated with a digest. We likely will change this in the next few weeks so that GitHub\nreleases are tags, and the \"digests\" are flie names. Stay tuned for updates!\n\n## Getting Started\n\n### 1. Template or Fork\n\nIf you haven't already, template or fork this repository. You can then clone\nyour fork:\n\n```bash\n$ git clone git@github.com:\u003cusername\u003e/singularity-deploy\n```\n\nYou likely want to name the repository by the container. For example, if I would\nhave created a container on Docker Hub or similar with the name `vsoch/salad`,\nhere I'd call the repository `salad`. You obviously are limited to your username\nor an organizational namespace.\n\n### 1. Write your Singularity Recipe(s)\n\nFirst, you should write your container recipe(s) in the present working directory.\nFor good practice, when you are updating recipes you should checkout a new branch\nand open a pull request, as the repository comes with a workflow to trigger on a PR\nto [test your container build](.github/workflows/test.yml). Note that in the main workflow\nthat deploys the releases, the current branch is set to be `main-branch`. You should\nupdate this to be your main \"production\" branch that you want to deploy releases on merge.\nYou are also free to choose a different trigger and release strategy. You can add any additional\ntests that that you might need. By default, any Singularity.* file will be automatically detected. \nIf there is no extension (the name Singularity), the name used will be \"latest.\" \nYou can use these tags across multiple releases of your containers. For example,\nthese files would generate packages with sifs named as follows:\n\n - [Singularity](Singularity) maps to [https://github.com/singularityhub/singularity-deploy/releases/download/0.0.1/singularityhub-singularity-deploy.latest.sif](https://github.com/singularityhub/singularity-deploy/releases/download/0.0.1/singularityhub-singularity-deploy.latest.sif)\n - [Singularity.pokemon](Singularity.pokemon) maps to [https://github.com/singularityhub/singularity-deploy/releases/download/0.0.1/singularityhub-singularity-deploy.pokemon.sif](https://github.com/singularityhub/singularity-deploy/releases/download/0.0.1/singularityhub-singularity-deploy.pokemon.sif)\n - [Singularity.salad](Singularity.salad) maps to [https://github.com/singularityhub/singularity-deploy/releases/download/0.0.1/singularityhub-singularity-deploy.salad.sif](https://github.com/singularityhub/singularity-deploy/releases/download/0.0.1/singularityhub-singularity-deploy.salad.sif)\n\nFor each name, you can see the direct download URL contains the repository (singularityhub/singularity-deploy),\nYou should not use any `:` characters in either your container tag (the GitHub extension) or\nthe GitHub tags (the release tags) as this might interfere with parsing.\nThe GitHub release tag (0.0.1 in the example above) is discussed next.\n\n### 2. Update the VERSION file\n\nAny time that you prepare new container recipes, you should update the [VERSION](VERSION)\nfile. The way that this repository works is to generate a release based on the\nstring in `VERSION`. A version is just a tag, so it could be something like\n`0.0.1` or `0.0.1-slim`. Keep in mind that GitHub releases cannot have duplicated\nnames, so you should not repeat the same tag. Do not use `:` in your tag names.\nIf you do need to re-release a tag (not recommended if a user might be using it and then it's changed) you can manually delete\nthe release and the tag in the GitHub interface. This is a nice structure because it\nmeans you can have containers with different names under the same tag. In the example\nabove, we have each of \"pokemon,\" \"latest,\" and \"salad\" released under tag 0.0.1.\nThis is how it looks on GitHub:\n\n![img/releases.png](img/releases.png)\n\n### 3. How to Develop\n\nAs we mentioned previously, the container builds will be tested on a pull request,\nand the release will trigger on merge into your main branch (main). See the [.github/workflows/builder.yml](.github/workflows/builder.yml))\nto edit this. The idea is that you can:\n\n1. Develop your container via a development branch\n2. Open a pull request to test the container (the [.github/workflows/test.yml](.github/workflows/test.yml))\n3. On merge, your container will be released!\n\n### 4. How to pull\n\nTechnically, Singularity can pull just knowing the URL. For example:\n\n```bash\n$ singularity pull https://github.com/singularityhub/singularity-deploy/releases/download/0.0.1/singularityhub-singularity-deploy.latest.sif\n```\n\nHowever, the [singularity-hpc](singularity-hpc) tool (will be) designed to be able to parse and handle\nthese container uris automatically. For the containers here, you could do:\n\n```bash\n$ shpc pull gh://singularityhub/singularity-deploy/0.0.1:latest\n$ shpc pull gh://singularityhub/singularity-deploy/0.0.1:salad\n$ shpc pull gh://singularityhub/singularity-deploy/0.0.1:pokemon\n```\n\nor write the container URI into a registry entry:\n\n```\ngh: singularityhub/singularity-deploy\nlatest:\n  latest: \"0.0.1\"\ntags:\n  \"latest\": \"0.0.1\"\n  \"salad\": \"0.0.1\"\n  \"pokemon\": \"0.0.1\"\nmaintainer: \"@vsoch\"\nurl: https://github.com/singularityhub/singularity-deploy\n```\n\n(This part is still under development!)\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsingularityhub%2Fsingularity-deploy","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fsingularityhub%2Fsingularity-deploy","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsingularityhub%2Fsingularity-deploy/lists"}