[{"_1":2,"_153":-5,"_154":-5},"loaderData",{"_3":4,"_13":14,"_21":22,"_132":133},"root",{"_5":-5,"_6":-7,"_7":8,"_9":-7,"_10":11,"_12":-7},"currentUser","primaryEmail","siteVerification","6LeIxAcTAAAAAJcZVRqyHh71UMIEGNQ_MXjiZKhI","toast","enableDev",false,"incidentStatus","routes/_layout",{"_15":-5,"_16":17,"_18":17,"_19":11,"_20":11},"username","isAskGordonEnabled",true,"isUsingNewTemplate","showMinimalLanding","showHoneypotTrap","routes/_layout.r.$namespace.$reponame",{"_23":24,"_25":-5,"_26":11,"_27":11,"_28":29,"_30":31,"_32":-5,"_33":11,"_34":35,"_83":-5,"_84":85,"_125":-5,"_126":11,"_127":17,"_128":11,"_129":-5,"_130":131},"canonicalUrl","https://hub.docker.com/r/fgimenez/hubot/tags","mcpServer","canSeeDockerfile","canSeeAutobuilds","namespace","fgimenez","reponame","hubot","cloudBuildSource","isAutobuildsAvailable","repo",{"_36":37,"_38":39,"_41":42,"_43":31,"_44":11,"_45":46,"_47":48,"_49":50,"_52":31,"_28":29,"_53":54,"_55":-5,"_56":57,"_58":59,"_60":61,"_62":-5,"_63":57,"_64":65,"_66":11,"_67":29,"_68":69,"_74":17,"_75":76,"_80":29,"_81":82},"categories",[],"content_types",[40],"image","date_registered","2016-05-31T16:18:43.349001Z","description","is_private","last_updated","2016-06-01T16:45:00.894851Z","last_modified","2024-10-16T13:48:34.145251Z","media_types",[51],"application/vnd.docker.container.image.v1+json","name","pull_count",1114,"repository_type","star_count",0,"status",1,"status_description","active","source","collaborator_count","full_description","[![Build Status][travis-image]][travis-url]\n# Snappy Jenkins CI\n\nThis repo helps setting up the CI and CD environment used for Snappy related projects, including [https://github.com/ubuntu-core/snappy](Snappy itself) and [https://github.com/ubuntu-core/snapcraft](Snapcraft). It contains Dockerfiles which define the required containers (Jenkins master and slaves and a Nginx proxy) and several shell scripts for bringing them to live both in a cloud provider (only OpenStack supported at the moment) and locally.\n\nThe testing jenkins jobs use the `snappy-cloud-client` binary from [https://launchpad.net/snappy-tests-job](this project) for launching the tests in cloud instances, it takes care of determining the most recent Snappy cloud image for a given channel and release (see below for the required name patterns), instantiating a cloud instance of that image and getting its ip. Then they execute the integration suite in the instance, shut it down when finished or in case of errors and generates reports about the tests executed, including a subunit version of the result sent to a practitest backend and calculations about integration tests coverage.\n\nThere are also jobs configured for accessing the Snappy Product Integration environment. This gives a lot more flexibility when executing the tests not being only limited to cloud instances but also on hardware boards, however you must provide credentials for this service.\n\n## Provision\n\nThere are provision scripts for creating the CI environment locally and in the cloud. These scripts use docker-machine and docker-compose, so you need to have them installed, see [https://docs.docker.com/machine/install-machine/](here) and [https://docs.docker.com/compose/install/](here). Once the provision is finished you can use the common commands of machine and compose, for instance, to list the machines:\n\n docker-machine ls\n\nTo point your docker client to the engine in a local provisioned server:\n\n eval $(docker-machine env snappy-jenkins-local)\n\nThe cloud environment uses Docker Swarm as the container scheduler, the command it that case is:\n\n eval $(docker-machine env --swarm swarm-master-${OS_USERNAME}-${OS_REGION_NAME})\n\nMore on the OpenStack environment variables below.\n\nOnce that's done you can use your local docker client as if you were in the remote machine, try `docker info`, `docker images`, `docker ps` and the like.\n\nWith the client configured to connect to the remote host you can also use compose:\n\n docker-compose -f ./config/compose/cluster.yml down\n docker-compose -f ./config/compose/cluster.yml pull\n docker-compose -f ./config/compose/cluster.yml up -d\n\nMore on [https://docs.docker.com/machine/](docker-machine), [https://docs.docker.com/compose/](docker-compose) and [https://docs.docker.com/swarm/](docker swarm) at their respective project pages.\n\n### Local Provision\n\nWe have verified the installation and configured the provision script for using the docker-machine kvm driver, it can be installed following the instructions at [https://github.com/dhiltgen/docker-machine-kvm](the project page).\n\nYou can setup the enviroment locally by executing this command:\n\n $ ./bin/jenkins/local-provision.sh\n\nThis command creates four kinds of containers:\n\n* Jenkins master instance: the actual Jenkins server, the jobs, plugins and configuration options are stored here.\n\n* Jenkins slave instances: the jobs are executed in this containers. We have instances of different distributions so that we can get tests results from each of them.\n\n* Reverse proxy instance: it has an Nginx process listening on port 8081 that forwards requests to path ```/ghprbhook``` to the jenkins master instance. This is useful only for the cloud deployment, see below\n\n* Microservices used by the jenkins jobs, for example the [https://github.com/ubuntu-core/snapversion](snapversion) service used to query the snap store for core snap (kernel, gadget and os) versions.\n\nOnce the scripts finish you can check the machine ip executing `docker-machine ip snappy-jenkins-local` and access the jenkins master instance from the browser at ```http://:8080```\n\nIf you want to try the jobs you can download the credentials from an accessible running server, see `Initializing servers` below.\n\n### Cloud provision\n\nIn this case you need to have OpenStack credentials loaded, for example by sourcing a novarc file:\n\n $ source path/to/openstack/credentials/novarc\n\nBefore executing the provision script you should have at least the ```$OS_USERNAME``` and ```$OS_REGION_NAME``` environment variables set. This credentials are used for creating the hosts where the CI environment itself is going to run, and may be different to the ones used later for the Ubuntu Core instances, more on this later. The scripts also assume that you have a valid private key at `~/.canonistack/${OS_USERNAME}_${OS_REGION_NAME}.key`, if that's not the case you can pass the path as the last argument.\n\nThe cloud provision process begins consist of the creation of the swarm cluster and later provision of the images, for it to work wee need firat to have set up the secrets and key-value backend, which can be done with this command (more on this in the Secrets section below):\n\n $ ./bin/secrets/cloud-provision.sh\n\nThen the swarm cluster can be created and the containers initially deployed with this is done with this single command:\n\n $ ./bin/jenkins/create-cluster.sh\n\nIt creates the swarm master, the nodes, pulls the container images, runs compose up and scales the required slaves.\n\nYou can retrieve the job history from an accessible running server, and also initialize the required credentials in order to run jobs, see `Syncing servers` below.\n\n## Redeploy\n\nOnce the cluster is deployed in order to update the containers you can use the redeploy script:\n\n $ ./bin/jenkins/cloud-redeploy.sh\n\nIt backups the jobs' history, stops the running containers, pulls the new images, restarts the cluster, restores the history, injects the credentials and cleans up leftover containers and volumes.\n\n## GitHub integration\n\nIn cloud deployments, the provision command sets up a security group that allows access to port 8081 from everywhere and ports 8080 and 22 from a local range (by default 10.0.0.0/8). All this configuration is done this way in order to facilitate a secure connection from the GitHub webhook.\n\n![Block Diagram](/img/snappy-jenkins.png?raw=true)\n\nThe Jenkins master container has the [https://wiki.jenkins-ci.org/display/JENKINS/GitHub+pull+request+builder+plugin](GitHub Pull Request Builder Plugin) installed to allow the triggering of jobs in response to events from GitHub. The default configuration in the container leaves almost all setup, there are only a few things left to do:\n\n* First of all, you should assign a floating IP to your VM instance so that it can be reached from GitHub. The container infrastructure and security group assigned make it secure to expose it to the wild, as explained earlier.\n\n* The ```github-snappy-integration-tests-cloud``` job is configured to receive payloads from GitHub in response to events. It points to the ubuntu-core/snappy repository, you can change this to access one of your own repos to try the hook.\n\n* In the settings page of the repository configured in ```github-snappy-integration-tests-cloud``` you should setup the webhook to notify Jenkins of changes in the repository, the URL should be ```http://:8081/ghprbhook/``` and the events to trigger the webhook \"Pull Request\" and \"Issue Comment\"\n\n* In order to be able to respond to comments in the pull request and update the status of the tests once they are triggered you should setup a bot user to be managed by Jenkins (a regular user works too). This user should be added as a collaborator in the repo and its credentials must be added in the jenkins general configuration (Manage Jenkins -> Configure System -> GitHub Pull Request Builder -> GitHub Auth -> Credentials -> Add).\n\n## Required images\n\nWith cloud provision, in order to spin up the jenkins host an image with a name of the form \"wily-daily-amd64\" should be accessible for the current user.\n\nWith both kinds of provision, for the jobs to be able to run your openstack user should be able to access snappy images with a name of the form ```ubuntu-core/custom/ubuntu-rolling-snappy-core-amd64-edge*``` for the rolling release tests and ```ubuntu-core/custom/ubuntu-1504-snappy-core-amd64-edge*``` for the 15.04 release tests. This kind of images can be created with the [https://github.com/ubuntu-core/snappy-cloud-image](snappy-cloud-image tool). The configuration can be changed with the release and channel switches in the respective jobs.\n\n## Data backup and restore\n\nThe job history can be saved and restored using the `./bin/jenkins/backup.sh` and `./bin/jenkins/restore.sh` scripts. Executing:\n\n $ ./bin/jenkins/backup.sh \n\ncreates a `backup.tar.gz` file in the current directory with all the existing executions of the jobs, being `` `local` or `remote` (default), and in both cases the client must be pointing to the matching docker engine.\n\nThese backup files can be restored to a running server with:\n\n $ ./bin/jenkins/restore.sh /path/to/backup/file \n\n## Secrets management\n\nWe use Hashicorp's [https://www.vaultproject.io/](Vault) to manage the secrets used by the jenkins deployment. There is a script for setting up this service on a cloud environment, you can provision it with:\n\n $ ./bin/secrets/cloud-provision.sh \n\nbeing `` the ssh key that the slaves will use for creating images and accessing instances created from them, and `` the path of the novarc file needed for accessing the cloud resources where the testbeds will be created. These secrets will be created under the vault path `secrets/jenkins/tests/ssh-key` and `secrets/jenkins/tests/openstack-credentials` respectively.\n\nAfter the provisioning, a `vault-remote.txt` text file is created in the current directory containing the server keys and root token, keep it safe because they are unique for each deployment.\n\nYou can also try the deployment locally with:\n\n $ ./bin/secrets/local-provision.sh\n\n`bin/secrets/inject.sh` gets the credentials from a vault server (see below) and puts them into a local or remote cluster. In order to execute this script you must be able to authenticate against the Vault server. It is executed with:\n\n $ ./bin/secrets/inject.sh \n\nwith `` being either `local` or `remote` (default).\n\nFinally, you can also backup and restore the credentials with the `./bin/secrets/backup.sh` and `./bin/secrets/restore.sh` scripts.\n\n[travis-image]: https://travis-ci.org/ubuntu-core/snappy-jenkins.svg?branch=master\n[travis-url]: https://travis-ci.org/ubuntu-core/snappy-jenkins\n","has_starred","hub_user","immutable_tags_settings",{"_70":11,"_71":72},"enabled","rules",[73],".*","is_automated","permissions",{"_77":17,"_78":11,"_79":11},"read","write","admin","user","storage_size",512985867,"orgData","recentTags",[86],{"_87":40,"_88":89,"_90":91,"_92":93,"_94":95,"_45":114,"_115":89,"_116":29,"_117":51,"_52":118,"_119":120,"_121":104,"_122":114,"_123":61,"_124":17},"content_type","creator",126060,"full_size",293374339,"id",3231491,"images",[96],{"_97":98,"_99":100,"_101":102,"_103":104,"_105":106,"_107":108,"_109":102,"_110":-5,"_111":112,"_58":61,"_113":-5},"architecture","amd64","digest","sha256:4f7fb20c58b25a4366936987f8f4e06845e062ad71db25d41b13fba848089504","features","","last_pulled","2026-09-20T18:16:55.844855246Z","last_pushed","2016-06-01T16:45:01Z","os","linux","os_features","os_version","size",293374211,"variant","2016-06-01T16:45:00.524664Z","last_updater","last_updater_username","media_type","latest","repository",717785,"tag_last_pulled","tag_last_pushed","tag_status","v2","sbxKitMetadata","isPotentialSpam","isHubSbxKitsEnabled","displaySecurityMetadata","tagAttestations","tagsHaveAttestations",[],"routes/_layout.r.$namespace.$reponame.tags",{"_34":134,"_141":142,"_130":151,"_152":11},{"_36":135,"_38":136,"_41":42,"_43":31,"_44":11,"_45":46,"_47":48,"_49":137,"_52":31,"_28":29,"_53":54,"_55":-5,"_56":57,"_58":59,"_60":61,"_62":-5,"_63":57,"_64":65,"_66":11,"_67":29,"_68":138,"_74":17,"_75":140,"_80":29,"_81":82},[],[40],[51],{"_70":11,"_71":139},[73],{"_77":17,"_78":11,"_79":11},"tags",{"_143":59,"_144":-5,"_145":-5,"_146":147},"count","next","previous","results",[148],{"_87":40,"_88":89,"_90":91,"_92":93,"_94":149,"_45":114,"_115":89,"_116":29,"_117":51,"_52":118,"_119":120,"_121":104,"_122":114,"_123":61,"_124":17},[150],{"_97":98,"_99":100,"_101":102,"_103":104,"_105":106,"_107":108,"_109":102,"_110":-5,"_111":112,"_58":61,"_113":-5},[],"canDeleteTags","actionData","errors"]

fgimenez/hubot

Tags for fgimenez/hubot