{"id":22599617,"url":"https://github.com/singularityhub/travis-ci","last_synced_at":"2025-07-27T05:36:40.394Z","repository":{"id":47256123,"uuid":"153518665","full_name":"singularityhub/travis-ci","owner":"singularityhub","description":"an example builder to build a container with Travis CI, and push to a Singularity Registry Server (or other endpoint)","archived":false,"fork":false,"pushed_at":"2021-09-06T13:43:07.000Z","size":255,"stargazers_count":7,"open_issues_count":0,"forks_count":10,"subscribers_count":4,"default_branch":"master","last_synced_at":"2025-04-11T01:41:33.667Z","etag":null,"topics":["builder","dropbox","google-storage","singularity","singularity-registry","singularityhub","sregistry","travis","travis-ci"],"latest_commit_sha":null,"homepage":"https://vsoch.github.io/2018/singularity-ci/","language":"Shell","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"agpl-3.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":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2018-10-17T20:21:26.000Z","updated_at":"2023-07-06T13:38:24.000Z","dependencies_parsed_at":"2022-09-01T23:03:09.628Z","dependency_job_id":null,"html_url":"https://github.com/singularityhub/travis-ci","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/singularityhub/travis-ci","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/singularityhub%2Ftravis-ci","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/singularityhub%2Ftravis-ci/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/singularityhub%2Ftravis-ci/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/singularityhub%2Ftravis-ci/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/singularityhub","download_url":"https://codeload.github.com/singularityhub/travis-ci/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/singularityhub%2Ftravis-ci/sbom","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":267306871,"owners_count":24067039,"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","status":"online","status_checked_at":"2025-07-27T02:00:11.917Z","response_time":82,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"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":["builder","dropbox","google-storage","singularity","singularity-registry","singularityhub","sregistry","travis","travis-ci"],"created_at":"2024-12-08T11:10:41.564Z","updated_at":"2025-07-27T05:36:40.360Z","avatar_url":"https://github.com/singularityhub.png","language":"Shell","readme":"# Singularity Builders Travis-CI\n\n![.travis/sregistry-travis.png](.travis/sregistry-travis.png)\n\n[![Build Status](https://travis-ci.org/singularityhub/travis-ci.svg?branch=master)](https://travis-ci.org/singularityhub/travis-ci)\n\nThis is a simple example of how you can achieve:\n\n - version control of your recipes\n - versioning to include image hash *and* commit id\n - build of associated container and\n - push to a storage endpoint\n\nfor a reproducible build workflow. This recipe on master is intended to build\nSingularity 3.x (with GoLang). If you are looking for legacy builds of Singularity,\nsee the [release/2.6](https://github.com/singularityhub/travis-ci/tree/release/2.6) branch.\n\n**Why should this be managed via Github?**\n\nGithub, by way of easy integration with continuous integration, is an easy way\nto have a workflow set up where multiple people can collaborate on a container recipe,\nthe recipe can be tested (with whatever testing you need), discussed in pull requests,\nand then finally pushed to the registry. Importantly, you don't need to give your\nentire team manager permissions to the registry. An encrypted credential that only\nis accessible to administrators can do the push upon merge of a discussed change.\n\n**Why should I use this instead of a service?**\n\nYou could use a remote builder, but if you do the build in a continuous integration\nservice you get complete control over it. This means everything from the version of\nSingularity to use, to the tests that you run for your container. You have a lot more\nfreedom in the rate of building, and organization of your repository, because it's you\nthat writes the configuration.\n\n## Quick Start\n\nAdd your Singularity recipes to this repository, and edit the build commands in\nthe [build.sh](.travis/build.sh) file. This is where you can specify endpoints \n(Singularity Registry, Dropbox, Google Storage, AWS) along with container names\n(the uri) and tag. You can build as many recipes as you like, just add another line!\n\n```yaml\n                               # recipe relative to repository base\n  - /bin/bash .travis/build.sh Singularity\n  - /bin/bash .travis/build.sh --uri collection/container --tag tacos --cli google-storage Singularity\n  - /bin/bash .travis/build.sh --uri collection/container --cli google-drive Singularity\n  - /bin/bash .travis/build.sh --uri collection/container --cli globus Singularity\n  - /bin/bash .travis/build.sh --uri collection/container --cli registry Singularity\n```\n\nFor each client that you use, required environment variables (e.g., credentials to push,\nor interact with the API) must be defined in the (encrypted) Travis environment. To\nknow what variables to define, along with usage for the various clients, see\nthe [client specific pages](https://singularityhub.github.io/sregistry-cli/clients)\n\n## Detailed Started\n\n### 0. Fork this repository\n\nYou can clone and tweak, but it's easiest likely to get started with our example\nfiles and edit them as you need.\n\n### 1. Get to Know Travis\n\nWe will be working with [Travis CI](https://www.travis-ci.org). You can see \nexample builds for this [repository here](https://travis-ci.org/singularityhub/travis-ci/builds).\n\n - Travis offers [cron jobs](https://docs.travis-ci.com/user/cron-jobs/) so you could schedule builds at some frequency.\n - Travis also offers [GPU Builders](https://circleci.com/docs/2.0/gpu/) if you want/need that sort of thing.\n - If you don't want to use the [sregistry](https://singularityhub.github.io/sregistry-cli) to push to Google Storage, Drive, Globus, Dropbox, or your personal Singularity Registry, travis will upload your artifacts directly to your [Amazon S3 bucket](https://docs.travis-ci.com/user/uploading-artifacts/).\n \n### 2. Add your Recipe(s)\n\nFor the example here, we have a single recipe named \"Singularity\" that is provided \nas an input argument to the [build script](.travis/build.sh). You could add another \nrecipe, and then of course call the build to happen more than once. \nThe build script will name the image based on the recipe, and you of course\ncan change this up.\n\n### 3. Configure Singularity\n\nThe basic steps to [setup](.travis/setup.sh) the build are the following:\n\n - Install Singularity from master branch. You could of course change the lines in [setup.sh](.travis/setup.sh) to use a specific tagged release, an older version, or development version.\n - Install the sregistry client, if needed. The [sregistry client](https://singularityhub.github.io/sregistry-cli) allows you to issue a command like \"sregistry push ...\" to upload a finished image to one of your cloud / storage endpoints. By default, this won't happen, and you will just build an image using the CI.\n\n### 4. Configure the Build\n\nThe basic steps for the [build](.travis/build.sh) are the following:\n\n - Running build.sh with no inputs will default to a recipe called \"Singularity\" in the base of the repository. You can provide an argument to point to a different recipe path, always relative to the base of your repository.\n - If you want to define a particular unique resource identifier for a finished container (to be uploaded to your storage endpoint) you can do that with `--uri collection/container`. If you don't define one, a robot name will be generated.\n - You can add `--uri` to specify a custom name, and this can include the tag, OR you can specify `--tag` to go along with a name without one. It depends on which is easier for you.\n - If you add `--cli` then this is telling the build script that you have defined the [needed environment variables](https://docs.travis-ci.com/user/environment-variables/#Defining-Variables-in-Repository-Settings) for your [client of choice](https://singularityhub.github.io/sregistry-cli/clients) and you want successful builds to be pushed to your storage endpoint. Valid clients include:\n    - google-storage\n    - google-drive\n    - dropbox\n    - globus\n    - registry (Singularity Registry)\n\nSee the [.travis.yml](.travis.yml) for examples of this build.sh command (commented out). If there is some cloud service that you'd like that is not provided, please [open an issue](https://www.github.com/singularityhub/sregistry-cli/issues).\n\n### 5. Connect to CI\n\nIf you go to your [Travis Profile](https://travis-ci.org/profile) you can usually select a Github organization (or user) and then the repository, and then click the toggle button to activate it to build on commit --\u003e push.\n\nThat's it for the basic setup! At this point, you will have a continuous integration service that will build your container from a recipe each time that you push. The next step is figuring out where you want to put the finished image(s), and we will walk through this in more detail.\n\n\n## Storage!\n\nOnce the image is built, where can you put it? An easy answer is to use the \n[Singularity Global Client](https://singularityhub.github.io/sregistry-cli) and\n choose [one of the many clients](https://singularityhub.github.io/sregistry-cli/clients) \nto add a final step to push the image. You then use the same client to pull the\ncontainer from your host. Once you've decided which endpoints you want to push to,\nyou will need to:\n\n 1. Save the credentials / other environment variables that your client needs (see the client settings page linked in the sregistry docs above) to your [repository settings](https://docs.travis-ci.com/user/environment-variables/#Defining-Variables-in-Repository-Settings) where they will be encrypted and in the environment.\n 2. Add a line to your [.travis.yml](.travis.yml) to do an sregistry push action to the endpoint(s) of choice. We have provided some (commented out) examples to get you started. \n\n## Travis Provided Uploads\nYou don't even need to use sregistry to upload a container (or an artifact / result produced from running one via a cron job maybe?) to an endpoint of choice! There are [many](https://docs.travis-ci.com/user/deployment) places you can deploy to. If you can think of it, it's on this list. Here are a sampling of some that I've tried (and generally like):\n\n - [Surge.sh](https://docs.travis-ci.com/user/deployment/surge/) gives you a little web address for free to upload content. This means that if your container runs an analysis and generates a web report, you can push it here. Each time you run it, you can push again and update your webby thing. Cool! Here is an [old example](http://containers-ftw.surge.sh/) of how I did this - the table you see was produced by a container and then the generated report uploaded to surge.\n - [Amazon S3](https://docs.travis-ci.com/user/deployment/s3/) bread and butter of object storage. sregistry doesn't have a client for it (bad dinosaur!) so I'll direct you to Travis to help :)\n - [Github Pages](https://docs.travis-ci.com/user/deployment/pages/) I want to point you to github pages in the case that your container has documentation that should be pushed when built afresh.\n\n\n## Advanced\n\nGuess what, this setup is totally changeable by you, it's your build! This means you can do any of the following \"advanced\" options:\n\n - This setup can work as an analysis node as well! Try setting up a [cron job](https://docs.travis-ci.com/user/cron-jobs/) to build a container that processes some information feed, and you have a regularly scheduled task.\n - try out one of the [GPU builders](https://circleci.com/docs/2.0/gpu/)\n - run builds in parallel and test different building environments. You could try building the \"same\" container across different machine types and see if you really do get the same thing :)\n - You can also do other sanity checks like testing if the container runs as you would expect, etc.\n","funding_links":[],"categories":[],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsingularityhub%2Ftravis-ci","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fsingularityhub%2Ftravis-ci","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsingularityhub%2Ftravis-ci/lists"}