Trigger openQA jobs via Jenkins
a project by bchou
Updated over 6 years ago. 7 hacker ♥️.

Try to use Jenkins 2.0 CI environments to trigger jobs which running in openQA

Topic 1: Keep learning Jenkins CI jenkinsci

Topic 2: Learn the Oliver's hackweek topic

Topic 3: Monitor a repository once new image was included

Topic 4: Trigger the openQA jobs via Jenkins

Topic 5: ...etc.

Join this project

Looking for hackers with the skills:

ci automation

This project is part of:

Hack Week 14

Activity

  • almost 9 years ago: pgeorgiadis liked this project.
  • over 9 years ago: david_chang liked this project.
  • over 9 years ago: bchou added keyword "automation" to this project.
  • over 9 years ago: bchou added keyword "ci" to this project.
  • over 9 years ago: Jeffreycheung liked this project.
  • over 9 years ago: XGWang0 joined this project.
  • over 9 years ago: bchou started this project.
  • over 9 years ago: okurz liked this project.
  • over 9 years ago: evshmarnev liked this project.
  • over 9 years ago: bchou originated this project.


    • Comments

    • bchou
      over 9 years ago by bchou | Reply

      Refer to other topic:

      Windows 10 in openQA https://hackweek.suse.com/14/projects/1468

    • bchou
      over 9 years ago by bchou | Reply

      Thanks for helps :) Cowork with XGWang about Jenkins hacks and discuss the openQA questions with okurz and WeiJiang.

      Hackweek Result: (Target is achieved)

      • 1. use [ScriptTrigger] - Poll with a shell or batch script in Jenkins

      Monitor the repository in our office(http://$server-ipaddres/iso/) once a new image was included in the repo. Thanks XGWang to Re-write a buildmonitor.py to do this job.

      $python /home/john/buildmonitor.py -u http://$server-ipaddres/iso/SLE12-SP2/ -p SLE-12-SP2-Server

      • 2. use Build item(Execute shell) in Jenkins

      Run the openQA script here.

      ISO=cat ${WORKSPACE}/SLE-12-SP2-Server

      $/usr/share/openqa/script/client --apikey xxx --apisecret yyy isos post ISO=${ISO} DISTRI=sle VERSION=12-SP2 FLAVOR=Server-DVD ARCH=x8664 HDDSIZEGB=20 QEMUCOMPRESSQCOW2=1 TEST=sles12sp2image_make

    Similar Projects

    Help Create A Chat Control Resistant Turnkey Chatmail/Deltachat Relay Stack - Rootless Podman Compose, OpenSUSE BCI, Hardened, & SELinux by 3nd5h1771fy

    Description

    The Mission: Decentralized & Sovereign Messaging

    FYI: If you have never heard of "Chatmail", you can visit their site here, but simply put it can be thought of as the underlying protocol/platform decentralized messengers like DeltaChat use for their communications. Do not confuse it with the honeypot looking non-opensource paid for prodect with better seo that directs you to chatmailsecure(dot)com

    In an era of increasing centralized surveillance by unaccountable bad actors (aka BigTech), "Chat Control," and the erosion of digital privacy, the need for sovereign communication infrastructure is critical. Chatmail is a pioneering initiative that bridges the gap between classic email and modern instant messaging, offering metadata-minimized, end-to-end encrypted (E2EE) communication that is interoperable and open.

    However, unless you are a seasoned sysadmin, the current recommended deployment method of a Chatmail relay is rigid, fragile, difficult to properly secure, and effectively takes over the entire host the "relay" is deployed on.

    Why This Matters

    A simple, host agnostic, reproducible deployment lowers the entry cost for anyone wanting to run a privacy‑preserving, decentralized messaging relay. In an era of perpetually resurrected chat‑control legislation threats, EU digital‑sovereignty drives, and many dangers of using big‑tech messaging platforms (Apple iMessage, WhatsApp, FB Messenger, Instagram, SMS, Google Messages, etc...) for any type of communication, providing an easy‑to‑use alternative empowers:

    • Censorship resistance - No single entity controls the relay; operators can spin up new nodes quickly.
    • Surveillance mitigation - End‑to‑end OpenPGP encryption ensures relay operators never see plaintext.
    • Digital sovereignty - Communities can host their own infrastructure under local jurisdiction, aligning with national data‑policy goals.

    By turning the Chatmail relay into a plug‑and‑play container stack, we enable broader adoption, foster a resilient messaging fabric, and give developers, activists, and hobbyists a concrete tool to defend privacy online.

    Goals

    As I indicated earlier, this project aims to drastically simplify the deployment of Chatmail relay. By converting this architecture into a portable, containerized stack using Podman and OpenSUSE base container images, we can allow anyone to deploy their own censorship-resistant, privacy-preserving communications node in minutes.

    Our goal for Hack Week: package every component into containers built on openSUSE/MicroOS base images, initially orchestrated with a single container-compose.yml (podman-compose compatible). The stack will:

    • Run on any host that supports Podman (including optimizations and enhancements for SELinux‑enabled systems).
    • Allow network decoupling by refactoring configurations to move from file-system constrained Unix sockets to internal TCP networking, allowing containers achieve stricter isolation.
    • Utilize Enhanced Security with SELinux by using purpose built utilities such as udica we can quickly generate custom SELinux policies for the container stack, ensuring strict confinement superior to standard/typical Docker deployments.
    • Allow the use of bind or remote mounted volumes for shared data (/var/vmail, DKIM keys, TLS certs, etc.).
    • Replace the local DNS server requirement with a remote DNS‑provider API for DKIM/TXT record publishing.

    By delivering a turnkey, host agnostic, reproducible deployment, we lower the barrier for individuals and small communities to launch their own chatmail relays, fostering a decentralized, censorship‑resistant messaging ecosystem that can serve DeltaChat users and/or future services adopting this protocol

    Resources

    Contribute to terraform-provider-libvirt by pinvernizzi

    Description

    The SUSE Manager (SUMA) teams' main tool for infrastructure automation, Sumaform, largely relies on terraform-provider-libvirt. That provider is also widely used by other teams, both inside and outside SUSE.

    It would be good to help the maintainers of this project and give back to the community around it, after all the amazing work that has been already done.

    If you're interested in any of infrastructure automation, Terraform, virtualization, tooling development, Go (...) it is also a good chance to learn a bit about them all by putting your hands on an interesting, real-use-case and complex project.

    Goals

    • Get more familiar with Terraform provider development and libvirt bindings in Go
    • Solve some issues and/or implement some features
    • Get in touch with the community around the project

    Resources

    Bring to Cockpit + System Roles capabilities from YAST by miguelpc

    Bring to Cockpit + System Roles features from YAST

    Cockpit and System Roles have been added to SLES 16 There are several capabilities in YAST that are not yet present in Cockpit and System Roles We will follow the principle of "automate first, UI later" being System Roles the automation component and Cockpit the UI one.

    Goals

    The idea is to implement service configuration in System Roles and then add an UI to manage these in Cockpit. For some capabilities it will be required to have an specific Cockpit Module as they will interact with a reasource already configured.

    Resources

    A plan on capabilities missing and suggested implementation is available here: https://docs.google.com/spreadsheets/d/1ZhX-Ip9MKJNeKSYV3bSZG4Qc5giuY7XSV0U61Ecu9lo/edit

    Linux System Roles:

    First meeting Hackweek catchup