├── .git-crypt ├── .gitattributes └── keys │ └── default │ └── 0 │ ├── 07E7A92F91D9B784155E8BE2341C151254EEBFC1.gpg │ ├── 0E1E13A03946B3AD866605351B43E8A6AC320AAF.gpg │ ├── 19EFE04401A2AD46BFF3E69412EF3812A619B753.gpg │ ├── 3D8C73EEF68B2237460418C38E8433A3F2D49E16.gpg │ ├── 3F2568AAC26998F9E813A1C5C3F436CA30F5D8EB.gpg │ ├── 4922ADBBB329AE3B8D0BECC072A6FB1D19BDCA9E.gpg │ ├── 7B87460E16927FA9F5BFF10C5937189AD3FBC665.gpg │ ├── 98FA15F3C926563B9ED462C9A6EC71273F83CDDE.gpg │ ├── A6672F0E5E8DA918F19EB6B8B64F48AF0EAD47B0.gpg │ └── BC187D207BC7842CF12893E250D40FCDAEBE19C5.gpg ├── .gitattributes ├── .github ├── ISSUE_TEMPLATE │ ├── api-staging-access.md │ ├── kernel-bug.md │ ├── new-tsc-member.md │ └── user-story.md └── workflows │ └── deploy.yml ├── .gitmodules ├── README.md ├── azure ├── costs.py ├── usage-2022-2023.json ├── usage-2023-21.json ├── usage-2023-22.json ├── usage-2023-23.json ├── usage-2023-24.json ├── usage-2023-25.json ├── usage-2023-26.json ├── usage-2023-27.json ├── usage-2023-28.json ├── usage-2023-29.json ├── usage-2023-30.json ├── usage-2023-31.json ├── usage-2023-32.json ├── usage-2023-33.json ├── usage-2023-34.json ├── usage-2023-35.json ├── usage-2023-36.json ├── usage-2023-37.json ├── usage-2023-38.json ├── usage-2023-39.json ├── usage-2023-40.json ├── usage-2023-41.json ├── usage-2023-42.json ├── usage-2023-43.json ├── usage-2023-44.json ├── usage-2023-45.json ├── usage-2023-46.json ├── usage-2023-47.json ├── usage-2023-48.json ├── usage-2023-49.json ├── usage-2023-50.json ├── usage-2023-51.json ├── usage-2023-52.json ├── usage-2024-01.json ├── usage-2024-02.json ├── usage-2024-03.json ├── usage-2024-04.json ├── usage-2024-05.json ├── usage-2024-06.json ├── usage-2024-07.json ├── usage-2024-08.json ├── usage-2024-09.json └── usage-2024-10.json ├── kernelci.org ├── .gitattributes ├── .gitignore ├── archetypes │ └── default.md ├── assets │ ├── icons │ │ ├── logo.png │ │ └── logo.svg │ └── scss │ │ └── _variables_project.scss ├── config.toml ├── content │ └── en │ │ ├── _index.md │ │ ├── about.md │ │ ├── admin │ │ ├── _index.md │ │ ├── api.md │ │ └── secrets.md │ │ ├── architecture │ │ ├── _index.md │ │ └── kernelci-architecture.svg │ │ ├── blog │ │ ├── .gitattributes │ │ ├── _index.html │ │ ├── news │ │ │ ├── 2019 │ │ │ │ ├── 10 │ │ │ │ │ └── 29 │ │ │ │ │ │ ├── techstartups.md │ │ │ │ │ │ └── zdnet.md │ │ │ │ └── 11 │ │ │ │ │ └── 11 │ │ │ │ │ └── thenewstack.md │ │ │ ├── 2020 │ │ │ │ └── 08 │ │ │ │ │ └── 19 │ │ │ │ │ ├── index.md │ │ │ │ │ └── kernelci-blog.png │ │ │ └── _index.html │ │ └── posts │ │ │ ├── 2020 │ │ │ ├── 11 │ │ │ │ └── 05 │ │ │ │ │ └── index.html │ │ │ ├── 05 │ │ │ │ └── 11 │ │ │ │ │ ├── featured-image-blog2.png │ │ │ │ │ └── index.html │ │ │ ├── 07 │ │ │ │ └── 09 │ │ │ │ │ ├── ci-system-usage-1024px.png │ │ │ │ │ ├── index.html │ │ │ │ │ ├── kernelci-community-survey-report-1200x325-1.png │ │ │ │ │ ├── reporting-1024px.png │ │ │ │ │ ├── response-time-1024px.png │ │ │ │ │ ├── roles-distribution-1024px.png │ │ │ │ │ └── upstream-contributions-1024px.png │ │ │ ├── 08 │ │ │ │ └── 21 │ │ │ │ │ ├── index.html │ │ │ │ │ ├── kcidb_object_relations.svg │ │ │ │ │ ├── kcidb_object_submitting.gif │ │ │ │ │ ├── patched_revision2.png │ │ │ │ │ └── revision1.png │ │ │ └── 09 │ │ │ │ └── 23 │ │ │ │ └── index.html │ │ │ ├── 2021 │ │ │ ├── .gitattributes │ │ │ ├── 03 │ │ │ │ └── 16 │ │ │ │ │ ├── index.html │ │ │ │ │ └── looking-back-looking-forward.png │ │ │ ├── 06 │ │ │ │ └── 24 │ │ │ │ │ └── index.html │ │ │ └── hackfests │ │ │ │ ├── hackfest-2-screenshot-2021-09-08-cropped.png │ │ │ │ └── index.md │ │ │ ├── 2022 │ │ │ ├── rfp-sysadmin │ │ │ │ ├── RFP-Sysadmin-Maintenance-2022-v3.pdf │ │ │ │ └── index.md │ │ │ └── sysadmin-onboard │ │ │ │ └── index.md │ │ │ ├── 2023 │ │ │ ├── api-early-access │ │ │ │ └── index.md │ │ │ ├── api-timeline │ │ │ │ └── index.md │ │ │ ├── fosdem-2023 │ │ │ │ └── index.md │ │ │ ├── rfp-ux-analysis-q-and-a │ │ │ │ └── index.md │ │ │ ├── rfp-ux-analysis │ │ │ │ ├── RFP-UX-Analysis-2023-v2.pdf │ │ │ │ └── index.md │ │ │ └── ux-analysis │ │ │ │ └── index.md │ │ │ ├── 2024 │ │ │ ├── strategic-updates │ │ │ │ └── index.md │ │ │ └── tsc-updates │ │ │ │ └── index.md │ │ │ └── _index.html │ │ ├── contacts.md │ │ ├── faq.md │ │ ├── kci-dev │ │ ├── kcidb │ │ ├── kernel-community │ │ ├── _index.md │ │ └── device-tests.md │ │ ├── labs │ │ └── _index.md │ │ ├── maestro │ │ ├── _index.md │ │ ├── api │ │ ├── contrib.md │ │ └── pipeline │ │ ├── org │ │ ├── _index.md │ │ ├── board.md │ │ ├── branding │ │ │ ├── _index.md │ │ │ ├── kernelci-logo-black.svg │ │ │ ├── kernelci-logo-color.png │ │ │ ├── kernelci-logo-color.svg │ │ │ ├── kernelci-logo-white.svg │ │ │ ├── kernelci_brand.pdf │ │ │ └── kernelci_brand.svg │ │ ├── lfx.md │ │ ├── maintainers.md │ │ ├── members.md │ │ ├── tsc │ │ │ ├── _index.md │ │ │ └── votes.md │ │ └── working-groups.md │ │ └── tests │ │ └── _index.md ├── data │ └── .placeholder ├── docker-compose.yaml ├── layouts │ └── partials │ │ └── navbar.html └── static │ ├── favicons │ ├── android-144x144.png │ ├── android-192x192.png │ ├── android-36x36.png │ ├── android-48x48.png │ ├── android-72x72.png │ ├── android-96x96.png │ ├── favicon-1024.png │ ├── favicon-16x16.png │ ├── favicon-256.png │ ├── favicon-32x32.png │ └── favicon.ico │ ├── files │ ├── KernelCI_Participation_Agreement_and_Funding_Charter_20180913.pdf │ └── KernelCI_Project_Technical_Charter_20181107.pdf │ └── image │ ├── baylibre-horizontal-color.svg │ ├── cip-stacked-color.svg │ ├── collabora-stacked-color.svg │ ├── elisa-horizontal-color.svg │ ├── google-color.svg │ ├── kernelci-horizontal-color.png │ ├── linaro-color.svg │ ├── microsoft-color.svg │ ├── redhat-color.svg │ └── texas-instruments.svg └── secrets ├── dump.py └── passwords.toml /.git-crypt/.gitattributes: -------------------------------------------------------------------------------- 1 | # Do not edit this file. To specify the files to encrypt, create your own 2 | # .gitattributes file in the directory where your files are. 3 | * !filter !diff 4 | *.gpg binary 5 | -------------------------------------------------------------------------------- /.git-crypt/keys/default/0/07E7A92F91D9B784155E8BE2341C151254EEBFC1.gpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/.git-crypt/keys/default/0/07E7A92F91D9B784155E8BE2341C151254EEBFC1.gpg -------------------------------------------------------------------------------- /.git-crypt/keys/default/0/0E1E13A03946B3AD866605351B43E8A6AC320AAF.gpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/.git-crypt/keys/default/0/0E1E13A03946B3AD866605351B43E8A6AC320AAF.gpg -------------------------------------------------------------------------------- /.git-crypt/keys/default/0/19EFE04401A2AD46BFF3E69412EF3812A619B753.gpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/.git-crypt/keys/default/0/19EFE04401A2AD46BFF3E69412EF3812A619B753.gpg -------------------------------------------------------------------------------- /.git-crypt/keys/default/0/3D8C73EEF68B2237460418C38E8433A3F2D49E16.gpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/.git-crypt/keys/default/0/3D8C73EEF68B2237460418C38E8433A3F2D49E16.gpg -------------------------------------------------------------------------------- /.git-crypt/keys/default/0/3F2568AAC26998F9E813A1C5C3F436CA30F5D8EB.gpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/.git-crypt/keys/default/0/3F2568AAC26998F9E813A1C5C3F436CA30F5D8EB.gpg -------------------------------------------------------------------------------- /.git-crypt/keys/default/0/4922ADBBB329AE3B8D0BECC072A6FB1D19BDCA9E.gpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/.git-crypt/keys/default/0/4922ADBBB329AE3B8D0BECC072A6FB1D19BDCA9E.gpg -------------------------------------------------------------------------------- /.git-crypt/keys/default/0/7B87460E16927FA9F5BFF10C5937189AD3FBC665.gpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/.git-crypt/keys/default/0/7B87460E16927FA9F5BFF10C5937189AD3FBC665.gpg -------------------------------------------------------------------------------- /.git-crypt/keys/default/0/98FA15F3C926563B9ED462C9A6EC71273F83CDDE.gpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/.git-crypt/keys/default/0/98FA15F3C926563B9ED462C9A6EC71273F83CDDE.gpg -------------------------------------------------------------------------------- /.git-crypt/keys/default/0/A6672F0E5E8DA918F19EB6B8B64F48AF0EAD47B0.gpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/.git-crypt/keys/default/0/A6672F0E5E8DA918F19EB6B8B64F48AF0EAD47B0.gpg -------------------------------------------------------------------------------- /.git-crypt/keys/default/0/BC187D207BC7842CF12893E250D40FCDAEBE19C5.gpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/.git-crypt/keys/default/0/BC187D207BC7842CF12893E250D40FCDAEBE19C5.gpg -------------------------------------------------------------------------------- /.gitattributes: -------------------------------------------------------------------------------- 1 | .gitattributes !filter !diff 2 | secrets/** filter=git-crypt diff=git-crypt 3 | secrets/dump.py !filter !diff 4 | azure/** filter=git-crypt diff=git-crypt 5 | azure/costs.py !filter !diff 6 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/api-staging-access.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: API Staging Access 3 | about: Request to get a staging account for the new API 4 | title: Request API account for USER 5 | labels: '' 6 | assignees: 7 | - nuclearcat 8 | - JenySadadia 9 | --- 10 | 11 | Maestro has a staging instance running for development purposes. 12 | It allows users to request an account on the new KernelCI API to give it a try. You can also enable your trees, builds, and tests on it. Here is the [developer documentation](https://docs.kernelci.org/maestro/pipeline/developer-documentation/) for the same. 13 | 14 | [Staging deployment](https://github.com/kernelci/kernelci-api/tree/main/kube/aks) can already run a pipeline with KUnit, kselftest, kernel builds and boot tests. So please give it a go and create issues on GitHub and ask questions on the [mailing list](mailto:kernelci@lists.linux.dev), IRC `#kernelci` on libera.chat or [Discord](https://discord.gg/KWbrbWEyqb) with whatever you may find. 15 | 16 | Once the account request is accepted, a user account will be created by an admin and a random password will be sent to your email address. You can then use `kci user password update` to set your own password, `kci user verify` to verify your email address, and `kci user token` to get an API token. We'll also provide you with an AzureFiles share to use alongside the API, even though you may use any other storage as long as artifacts can be reached with a public HTTP URL. 17 | 18 | Please provide the required information below and also replace `USER` with your name or username in the issue title: 19 | 20 | * User name: 21 | * Email address: 22 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/kernel-bug.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Kernel Bug 3 | about: Any kernel issue discovered by KernelCI 4 | title: "`short git sha1` short description" 5 | assignees: '' 6 | 7 | --- 8 | 9 | * Commit: https://github.com/torvalds/linux/commit/ `` 10 | * Regressions: 11 | * https://linux.kernelci.org/test/case/id// 12 | * https://linux.kernelci.org/test/case/id// 13 | * Email: https://lore.kernel.org/lkml/ 14 | * Bisection report: 15 | ``` 16 | 17 | ``` 18 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/new-tsc-member.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: New TSC member 3 | about: Checklist to add a new TSC member 4 | title: "Add TSC member: FULL NAME" 5 | assignees: 'padovan' 6 | --- 7 | 8 | Please go through all the checklist below to add @_USERNAME_ (_FULL NAME_) as a member of the [TSC](https://docs.kernelci.org/org/tsc/): 9 | 10 | - [ ] [TSC voting record](https://docs.kernelci.org/org/tsc/votes/) added to the documentation 11 | - [ ] [TSC members](https://docs.kernelci.org/org/tsc/#members) documentation updated with new member's name, email and IRC nickname 12 | - [ ] New member invited to join [`kernelci-tsc@groups.io`](https://groups.io/g/kernelci-tsc) 13 | - [ ] New member invited to the [monthly TSC meeting](https://docs.kernelci.org/org/#technical-steering-committee) 14 | - [ ] TSC documents shared with the new member (meeting minutes in Google Docs etc.) 15 | - [ ] New member invited to any relevant private channels (if applicable) 16 | - [ ] Induction about [TSC rules and duties](https://docs.kernelci.org/org/tsc/#rules) with Chair or other committee members completed 17 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/user-story.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: User Story 3 | about: Formatted user story for UX improvement 4 | title: ": " 5 | assignees: '' 6 | 7 | --- 8 | 9 | *Please replace the words in capital letters below with your own:* 10 | 11 | **As USER PERSONA, I want to USER INTENT so USER BENEFIT.** 12 | 13 | *For example: As a kernel hacker, I want to be notified about bugs so I can fix them.* 14 | 15 | ## Background 16 | 17 | *Please provide any extra information about this user story such as what led you to create it or any examples to illustrate it.* 18 | 19 | ## Thank you! 20 | 21 | Thanks for adding a user story and contributing to improving KernelCI's user experience. It should soon appear on the user experience [workboard](https://github.com/orgs/kernelci/projects/18/) so we can keep track of it. 22 | 23 | *This issue template was inspired by an [Atlassian article](https://www.atlassian.com/agile/project-management/user-stories) on user stories.* 24 | -------------------------------------------------------------------------------- /.github/workflows/deploy.yml: -------------------------------------------------------------------------------- 1 | name: Hugo Website Deploy 2 | 3 | on: 4 | issue_comment: 5 | types: [created, edited] 6 | workflow_dispatch: 7 | inputs: 8 | environment: 9 | description: 'Environment to deploy to' 10 | type: choice 11 | required: true 12 | default: 'staging' 13 | options: 14 | - staging 15 | - production 16 | push: 17 | branches: 18 | - main 19 | 20 | jobs: 21 | deploy_staging: 22 | if: | 23 | (github.event.issue.pull_request && contains('["nuclearcat","JenySadadia","a-wai","broonie","padovan", "patersonc"]', github.actor) && contains(github.event.comment.body, '/staging')) || 24 | (github.event_name == 'workflow_dispatch' && contains('["nuclearcat","JenySadadia","a-wai","broonie","padovan", "patersonc"]', github.actor)) || 25 | (github.event_name == 'push' && github.ref == 'refs/heads/main') 26 | runs-on: ubuntu-22.04 27 | environment: stagingdeploy 28 | permissions: 29 | issues: write 30 | pull-requests: write 31 | steps: 32 | - name: Checkout PR branch 33 | uses: actions/checkout@v4 34 | if: github.event_name == 'issue_comment' 35 | with: 36 | submodules: recursive # Fetch Hugo themes (true OR recursive) 37 | fetch-depth: 0 # Fetch all history for .GitInfo and .Lastmod 38 | lfs: true # Fetch Git LFS files 39 | ref: refs/pull/${{ github.event.issue.number }}/head 40 | 41 | - name: Checkout main branch 42 | uses: actions/checkout@v4 43 | if: github.event_name == 'workflow_dispatch' || github.event_name == 'push' 44 | with: 45 | submodules: recursive # Fetch Hugo themes (true OR recursive) 46 | fetch-depth: 0 # Fetch all history for .GitInfo and .Lastmod 47 | lfs: true # Fetch Git LFS files 48 | ref: main 49 | # TODO: Fix this more elegantly 50 | - name: Submodules init 51 | run: git submodule update --init --recursive 52 | - name: Update submodule kernelci-pipeline 53 | run: cd kernelci.org/external/kernelci-pipeline;git pull origin main 54 | - name: Update submodule kernelci-api 55 | run: cd kernelci.org/external/kernelci-api;git pull origin main 56 | - name: Update submodule kernelci-core 57 | run: cd kernelci.org/external/kernelci-core;git pull origin main 58 | - name: Update submodule kcidb 59 | run: cd kernelci.org/external/kcidb;git pull origin main 60 | - name: Update submodule kci-dev 61 | run: cd kernelci.org/external/kci-dev;git pull origin main 62 | 63 | - name: Setup Hugo 64 | uses: peaceiris/actions-hugo@v3 65 | with: 66 | hugo-version: '0.97.3' 67 | extended: true 68 | 69 | - name: Setup Node.js 70 | uses: actions/setup-node@v4 71 | with: 72 | node-version: '20' 73 | 74 | - name: Install dependencies (postcss), bootstrap-sass 75 | run: npm install --save-dev autoprefixer && npm install postcss-cli && npm install -D postcss && npm install -D postcss-preset-env && npm install -D bootstrap-sass 76 | 77 | - name: Build staging 78 | if: github.event.inputs.environment == 'staging' || github.event_name == 'issue_comment' 79 | run: cd kernelci.org;hugo --minify -D -F -b https://static.staging.kernelci.org/ 80 | 81 | - name: Build production 82 | if: github.event_name == 'push' || github.event.inputs.environment == 'production' 83 | run: cd kernelci.org;hugo --minify -D -F -b https://kernelci.org/ 84 | 85 | - name: rsync staging deployment 86 | if: github.event.inputs.environment == 'staging' || github.event_name == 'issue_comment' 87 | uses: burnett01/rsync-deployments@7.0.1 88 | with: 89 | switches: -avzr --delete 90 | path: kernelci.org/public/ 91 | remote_path: ${{ secrets.WEB_STAGING_DIR }} 92 | remote_host: ${{ secrets.WEB_STAGING_HOST }} 93 | remote_port: ${{ secrets.WEB_STAGING_PORT }} 94 | remote_user: ${{ secrets.WEB_STAGING_USERNAME }} 95 | remote_key: ${{ secrets.WEB_STAGING_KEY }} 96 | 97 | - name: Leave comment in issue about staging URL 98 | if: github.event.inputs.environment == 'staging' || github.event_name == 'issue_comment' 99 | run: | 100 | gh issue comment "$NUMBER" --body "$BODY" 101 | env: 102 | GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} 103 | GH_REPO: ${{ github.repository }} 104 | NUMBER: ${{ github.event.issue.number }} 105 | BODY: > 106 | Your PR has been deployed to staging. 107 | Staging URL: https://static.staging.kernelci.org/ 108 | After testing, you can merge your PR. 109 | Note: This is a temporary staging URL, if anyone else will test another PR, it will override contents. 110 | 111 | - name: rsync production deployment 112 | if: github.event_name == 'push' || github.event.inputs.environment == 'production' 113 | uses: burnett01/rsync-deployments@7.0.1 114 | with: 115 | switches: -avzr --delete 116 | path: kernelci.org/public/ 117 | remote_path: ${{ secrets.WEB_PRODUCTION_DIR }} 118 | remote_host: ${{ secrets.WEB_PRODUCTION_HOST }} 119 | remote_port: ${{ secrets.WEB_PRODUCTION_PORT }} 120 | remote_user: ${{ secrets.WEB_PRODUCTION_USERNAME }} 121 | remote_key: ${{ secrets.WEB_PRODUCTION_KEY }} 122 | -------------------------------------------------------------------------------- /.gitmodules: -------------------------------------------------------------------------------- 1 | [submodule "kernelci.org/themes/docsy"] 2 | path = kernelci.org/themes/docsy 3 | url = https://github.com/google/docsy.git 4 | [submodule "kernelci.org/external/kernelci-core"] 5 | path = kernelci.org/external/kernelci-core 6 | url = https://github.com/kernelci/kernelci-core.git 7 | [submodule "kernelci.org/external/kernelci-api"] 8 | path = kernelci.org/external/kernelci-api 9 | url = https://github.com/kernelci/kernelci-api.git 10 | [submodule "kernelci.org/external/kcidb"] 11 | path = kernelci.org/external/kcidb 12 | url = https://github.com/kernelci/kcidb.git 13 | [submodule "kernelci.org/external/kernelci-pipeline"] 14 | path = kernelci.org/external/kernelci-pipeline 15 | url = https://github.com/kernelci/kernelci-pipeline.git 16 | [submodule "kernelci.org/external/kci-dev"] 17 | path = kernelci.org/external/kci-dev 18 | url = https://github.com/kernelci/kci-dev 19 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | KernelCI project logo 4 | 5 | KernelCI project 6 | ================ 7 | 8 | KernelCI is a Linux Foundation project dedicated to testing the upstream [Linux 9 | kernel](https://kernel.org). 10 | 11 | Mission statement: 12 | 13 | > To ensure the quality, stability and long-term maintenance of the Linux 14 | > kernel by maintaining an open ecosystem around test automation practices and 15 | > principles. 16 | 17 | This repository contains general documentation about the project. 18 | 19 | 20 | Documentation website 21 | ===================== 22 | 23 | The source code of [docs.kernelci.org](https://docs.kernelci.org) static pages is 24 | contained in the [`kernelci.org`](kernelci.org) directory. It uses the 25 | [Hugo](https://gohugo.io) framework. 26 | 27 | To set up a local development server with Docker: 28 | 29 | ```sh 30 | $ git clone https://github.com/kernelci/kernelci-project.git 31 | $ cd kernelci-project 32 | $ sudo apt install -y git-lfs 33 | $ git-lfs fetch 34 | $ git-lfs checkout 35 | $ git submodule update --init --recursive 36 | $ cd kernelci.org 37 | ``` 38 | 39 | Then to start the server: 40 | ```sh 41 | $ docker run -v $PWD:/src -p 1313:1313 klakegg/hugo:0.97.3-ext-debian server -D 42 | ``` 43 | 44 | Alternatively, this can be started with `docker-compose`: 45 | 46 | ```sh 47 | docker-compose up 48 | ``` 49 | 50 | Then open http://localhost:1313 in your browser. 51 | 52 | Secrets and git-crypt 53 | ===================== 54 | 55 | The [`secrets`](https://github.com/kernelci/kernelci-project/tree/main/secrets) 56 | directory contains encrypted files with credentials used by the KernelCI 57 | project. See the [Secrets](https://docs.kernelci.org/admin/secrets/) page for 58 | more details about how it is used. 59 | -------------------------------------------------------------------------------- /azure/costs.py: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env python3 2 | # 3 | # SPDX-License-Identifier: LGPL-2.1-or-later 4 | # 5 | # Copyright (C) 2023 Collabora Limited 6 | # Author: Guillaume Tucker 7 | 8 | """Azure sponsorship usage parser""" 9 | 10 | import argparse 11 | import datetime 12 | import json 13 | 14 | COLORS = { 15 | 'green': '\033[92m', 16 | 'yellow': '\033[93m', 17 | 'red': '\033[91m', 18 | 'blue': '\033[94m', 19 | 'bold': '\033[1m', 20 | 'underline': '\033[4m', 21 | 'clear': '\033[0m', 22 | } 23 | 24 | 25 | def _color(msg, color): 26 | return ''.join([COLORS[color], msg, COLORS['clear']]) 27 | 28 | 29 | def _bold(msg): 30 | return _color(msg, 'bold') 31 | 32 | 33 | def _under(msg): 34 | return _color(msg, 'underline') 35 | 36 | 37 | class Usage: 38 | """Usage data parser 39 | 40 | This class takes the raw JSON data with the Azure subscription usage and 41 | provides methods for analysing it. The sub_id optional argument is to 42 | filter data for only one subscription GUID. 43 | """ 44 | 45 | def __init__(self, usage, sub_id=None): 46 | self._usage = usage 47 | self._sub_id = sub_id 48 | if self._sub_id: 49 | self._usage = list(self._filter_by_subscription()) 50 | 51 | def __getitem__(self, index): 52 | return self._usage[index] 53 | 54 | def __len__(self): 55 | return len(self._usage) 56 | 57 | def _filter_by_subscription(self): 58 | for entry in self._usage: 59 | if entry['SubscriptionGuid'] == self._sub_id: 60 | yield entry 61 | 62 | @property 63 | def subscription_guid(self): 64 | """Azure subscription GUID""" 65 | return self._sub_id 66 | 67 | @classmethod 68 | def from_json(cls, json_path, sub_id=None): 69 | """Create a Usage object from a JSON file path""" 70 | with open(json_path, encoding='utf-8') as usage_file: 71 | return Usage(json.load(usage_file), sub_id) 72 | 73 | def by_date(self): 74 | """Get the data in a dictionary with dates as keys""" 75 | usage_by_date = {} 76 | for entry in self._usage: 77 | when = datetime.datetime.fromisoformat(entry['Date']) 78 | usage_data = usage_by_date.setdefault(when, []) 79 | usage_data.append(entry) 80 | return usage_by_date 81 | 82 | def by_category(self): 83 | """Get the data in a dictionary with categories as keys""" 84 | usage_by_cat = {} 85 | for entry in self._usage: 86 | cat = usage_by_cat.setdefault(entry['ServiceName'], []) 87 | cat.append(entry) 88 | return usage_by_cat 89 | 90 | @classmethod 91 | def totals(cls, data): 92 | """Get the total cost for a dictionary of entries""" 93 | return { 94 | key: sum(entry['Cost'] for entry in item) 95 | for key, item in data.items() 96 | } 97 | 98 | 99 | def _show_details(usage): 100 | for when, item in usage.by_date().items(): 101 | date = when.strftime('%Y-%m-%d') 102 | for entry in item: 103 | service, resource, region, cost = ( 104 | entry[key] for key in [ 105 | 'ServiceName', 106 | 'ServiceResource', 107 | 'ServiceRegion', 108 | 'Cost' 109 | ]) 110 | print(f"{date} {service:24s} {cost:8.2f} {region:24} {resource}") 111 | 112 | 113 | def _show_daily_totals(usage, details=True): 114 | by_date = usage.by_date() 115 | dates = list(by_date.keys()) 116 | totals = usage.totals(by_date) 117 | full_total = 0 118 | dates = sorted(totals.keys()) 119 | for when in dates: 120 | total = totals[when] 121 | full_total += total 122 | if details: 123 | print(f"{when.strftime('%Y-%m-%d')} {total:8.2f}") 124 | delta = max(dates) - min(dates) 125 | average = full_total / (delta.days + 1) 126 | if details: 127 | print("-------------------") 128 | print(f"Total: {full_total:8.2f}") 129 | print(f"Average: {average:8.2f}") 130 | 131 | 132 | def _show_category_totals(usage): 133 | totals = usage.totals(usage.by_category()) 134 | swapped = {total: cat for cat, total in totals.items()} 135 | for total in reversed(sorted(swapped.keys())): 136 | cat = swapped[total] 137 | print(f"{cat:24s} {total:8.2f}") 138 | 139 | 140 | def main(args): 141 | """Entry point for the command line interface""" 142 | usage = Usage.from_json(args.usage, args.subscription) 143 | if args.daily_detail: 144 | print(_bold("Detailed log:")) 145 | _show_details(usage) 146 | print() 147 | if args.categories: 148 | print(_bold("Total per category")) 149 | _show_category_totals(usage) 150 | print() 151 | print(_bold("Daily totals")) 152 | _show_daily_totals(usage, args.daily_totals) 153 | 154 | 155 | if __name__ == '__main__': 156 | parser = argparse.ArgumentParser("Parse Azure sponsorship costs") 157 | parser.add_argument( 158 | 'usage', 159 | help="Path to the JSON Azure usage file" 160 | ) 161 | parser.add_argument( 162 | '--subscription', 163 | default='fd1f9aff-ce5e-4029-93c2-a2fa279f9b9f', 164 | help="Subscription UUID" 165 | ) 166 | parser.add_argument( 167 | '--daily-detail', 168 | action='store_true', 169 | help="Show the daily detailed log" 170 | ) 171 | parser.add_argument( 172 | '--daily-totals', 173 | action='store_true', 174 | help="Show the daily totals" 175 | ) 176 | parser.add_argument( 177 | '--categories', 178 | action='store_true', 179 | help="Show the total costs per category" 180 | ) 181 | main(parser.parse_args()) 182 | -------------------------------------------------------------------------------- /azure/usage-2022-2023.json: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/azure/usage-2022-2023.json -------------------------------------------------------------------------------- /azure/usage-2023-21.json: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/azure/usage-2023-21.json -------------------------------------------------------------------------------- /azure/usage-2023-22.json: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/azure/usage-2023-22.json -------------------------------------------------------------------------------- /azure/usage-2023-23.json: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/azure/usage-2023-23.json -------------------------------------------------------------------------------- /azure/usage-2023-24.json: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/azure/usage-2023-24.json -------------------------------------------------------------------------------- /azure/usage-2023-25.json: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/azure/usage-2023-25.json -------------------------------------------------------------------------------- /azure/usage-2023-26.json: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/azure/usage-2023-26.json -------------------------------------------------------------------------------- /azure/usage-2023-27.json: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/azure/usage-2023-27.json -------------------------------------------------------------------------------- /azure/usage-2023-28.json: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/azure/usage-2023-28.json -------------------------------------------------------------------------------- /azure/usage-2023-29.json: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/azure/usage-2023-29.json -------------------------------------------------------------------------------- /azure/usage-2023-30.json: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/azure/usage-2023-30.json -------------------------------------------------------------------------------- /azure/usage-2023-31.json: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/azure/usage-2023-31.json -------------------------------------------------------------------------------- /azure/usage-2023-32.json: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/azure/usage-2023-32.json -------------------------------------------------------------------------------- /azure/usage-2023-33.json: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/azure/usage-2023-33.json -------------------------------------------------------------------------------- /azure/usage-2023-34.json: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/azure/usage-2023-34.json -------------------------------------------------------------------------------- /azure/usage-2023-35.json: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/azure/usage-2023-35.json -------------------------------------------------------------------------------- /azure/usage-2023-36.json: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/azure/usage-2023-36.json -------------------------------------------------------------------------------- /azure/usage-2023-37.json: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/azure/usage-2023-37.json -------------------------------------------------------------------------------- /azure/usage-2023-38.json: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/azure/usage-2023-38.json -------------------------------------------------------------------------------- /azure/usage-2023-39.json: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/azure/usage-2023-39.json -------------------------------------------------------------------------------- /azure/usage-2023-40.json: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/azure/usage-2023-40.json -------------------------------------------------------------------------------- /azure/usage-2023-41.json: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/azure/usage-2023-41.json -------------------------------------------------------------------------------- /azure/usage-2023-42.json: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/azure/usage-2023-42.json -------------------------------------------------------------------------------- /azure/usage-2023-43.json: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/azure/usage-2023-43.json -------------------------------------------------------------------------------- /azure/usage-2023-44.json: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/azure/usage-2023-44.json -------------------------------------------------------------------------------- /azure/usage-2023-45.json: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/azure/usage-2023-45.json -------------------------------------------------------------------------------- /azure/usage-2023-46.json: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/azure/usage-2023-46.json -------------------------------------------------------------------------------- /azure/usage-2023-47.json: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/azure/usage-2023-47.json -------------------------------------------------------------------------------- /azure/usage-2023-48.json: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/azure/usage-2023-48.json -------------------------------------------------------------------------------- /azure/usage-2023-49.json: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/azure/usage-2023-49.json -------------------------------------------------------------------------------- /azure/usage-2023-50.json: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/azure/usage-2023-50.json -------------------------------------------------------------------------------- /azure/usage-2023-51.json: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/azure/usage-2023-51.json -------------------------------------------------------------------------------- /azure/usage-2023-52.json: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/azure/usage-2023-52.json -------------------------------------------------------------------------------- /azure/usage-2024-01.json: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/azure/usage-2024-01.json -------------------------------------------------------------------------------- /azure/usage-2024-02.json: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/azure/usage-2024-02.json -------------------------------------------------------------------------------- /azure/usage-2024-03.json: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/azure/usage-2024-03.json -------------------------------------------------------------------------------- /azure/usage-2024-04.json: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/azure/usage-2024-04.json -------------------------------------------------------------------------------- /azure/usage-2024-05.json: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/azure/usage-2024-05.json -------------------------------------------------------------------------------- /azure/usage-2024-06.json: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/azure/usage-2024-06.json -------------------------------------------------------------------------------- /azure/usage-2024-07.json: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/azure/usage-2024-07.json -------------------------------------------------------------------------------- /azure/usage-2024-08.json: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/azure/usage-2024-08.json -------------------------------------------------------------------------------- /azure/usage-2024-09.json: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/azure/usage-2024-09.json -------------------------------------------------------------------------------- /azure/usage-2024-10.json: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/azure/usage-2024-10.json -------------------------------------------------------------------------------- /kernelci.org/.gitattributes: -------------------------------------------------------------------------------- 1 | static/favicons/favicon.ico filter=lfs diff=lfs merge=lfs -text 2 | static/favicons/android-144x144.png filter=lfs diff=lfs merge=lfs -text 3 | static/favicons/android-36x36.png filter=lfs diff=lfs merge=lfs -text 4 | static/favicons/android-72x72.png filter=lfs diff=lfs merge=lfs -text 5 | static/favicons/android-96x96.png filter=lfs diff=lfs merge=lfs -text 6 | static/favicons/favicon-16x16.png filter=lfs diff=lfs merge=lfs -text 7 | static/favicons/favicon-256.png filter=lfs diff=lfs merge=lfs -text 8 | static/favicons/favicon-32x32.png filter=lfs diff=lfs merge=lfs -text 9 | static/favicons/android-192x192.png filter=lfs diff=lfs merge=lfs -text 10 | static/favicons/android-48x48.png filter=lfs diff=lfs merge=lfs -text 11 | static/favicons/favicon-1024.png filter=lfs diff=lfs merge=lfs -text 12 | assets/icons/logo.png filter=lfs diff=lfs merge=lfs -text 13 | content/en/background.jpeg filter=lfs diff=lfs merge=lfs -text 14 | content/en/about/background.jpeg filter=lfs diff=lfs merge=lfs -text 15 | static/files/KernelCI_Participation_Agreement_and_Funding_Charter_20180913.pdf filter=lfs diff=lfs merge=lfs -text 16 | static/files/KernelCI_Project_Technical_Charter_20181107.pdf filter=lfs diff=lfs merge=lfs -text 17 | content/en/logo/files/kernelci-logo-color.png filter=lfs diff=lfs merge=lfs -text 18 | content/en/logo/files/kernelci-logo-color.svg filter=lfs diff=lfs merge=lfs -text 19 | content/en/logo/files/kernelci-logo-white.svg filter=lfs diff=lfs merge=lfs -text 20 | content/en/logo/files/kernelci-logo-black.svg filter=lfs diff=lfs merge=lfs -text 21 | content/en/logo/background.jpeg filter=lfs diff=lfs merge=lfs -text 22 | content/en/logo/kernelci_brand.pdf filter=lfs diff=lfs merge=lfs -text 23 | content/en/logo/kernelci_brand.svg filter=lfs diff=lfs merge=lfs -text 24 | static/image/kernelci-architecture.png filter=lfs diff=lfs merge=lfs -text 25 | content/en/blog/news/2020/08/19/kernelci-blog.png filter=lfs diff=lfs merge=lfs -text 26 | content/en/blog/posts/2020/05/11/featured-image-blog2.png filter=lfs diff=lfs merge=lfs -text 27 | content/en/blog/posts/2020/07/09/ci-system-usage-1024px.png filter=lfs diff=lfs merge=lfs -text 28 | content/en/blog/posts/2020/07/09/kernelci-community-survey-report-1200x325-1.png filter=lfs diff=lfs merge=lfs -text 29 | content/en/blog/posts/2020/07/09/reporting-1024px.png filter=lfs diff=lfs merge=lfs -text 30 | content/en/blog/posts/2020/07/09/response-time-1024px.png filter=lfs diff=lfs merge=lfs -text 31 | content/en/blog/posts/2020/07/09/roles-distribution-1024px.png filter=lfs diff=lfs merge=lfs -text 32 | content/en/blog/posts/2020/07/09/upstream-contributions-1024px.png filter=lfs diff=lfs merge=lfs -text 33 | content/en/blog/posts/2020/08/21/patched_revision2.png filter=lfs diff=lfs merge=lfs -text 34 | content/en/blog/posts/2020/08/21/revision1.png filter=lfs diff=lfs merge=lfs -text 35 | content/en/blog/posts/2020/08/21/kcidb_object_relations.svg filter=lfs diff=lfs merge=lfs -text 36 | content/en/blog/posts/2020/08/21/kcidb_object_submitting.gif filter=lfs diff=lfs merge=lfs -text 37 | content/en/blog/posts/2021/03/16/looking-back-looking-forward.png filter=lfs diff=lfs merge=lfs -text 38 | static/image/kernelci-horizontal-color.png filter=lfs diff=lfs merge=lfs -text 39 | content/en/blog/posts/2022/rfp-sysadmin/RFP-Sysadmin-Maintenance-2022-v3.pdf filter=lfs diff=lfs merge=lfs -text 40 | -------------------------------------------------------------------------------- /kernelci.org/.gitignore: -------------------------------------------------------------------------------- 1 | resources/_gen 2 | public 3 | -------------------------------------------------------------------------------- /kernelci.org/archetypes/default.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "{{ replace .Name "-" " " | title }}" 3 | date: {{ .Date }} 4 | draft: true 5 | --- 6 | 7 | -------------------------------------------------------------------------------- /kernelci.org/assets/icons/logo.png: -------------------------------------------------------------------------------- 1 | version https://git-lfs.github.com/spec/v1 2 | oid sha256:fe7af9d8256eb63ccedce638bf29024f226d625fcaaa2ce9140a1a6a138a9f4d 3 | size 251051 4 | -------------------------------------------------------------------------------- /kernelci.org/assets/icons/logo.svg: -------------------------------------------------------------------------------- 1 | 2 | image/svg+xml -------------------------------------------------------------------------------- /kernelci.org/assets/scss/_variables_project.scss: -------------------------------------------------------------------------------- 1 | $primary: #009ade; 2 | $primary-light: lighten($primary, 75%); 3 | $secondary: #001b71; 4 | $dark: #222; 5 | $td-box-colors: $dark, $dark, $dark, $secondary, $secondary, $primary-light; 6 | -------------------------------------------------------------------------------- /kernelci.org/config.toml: -------------------------------------------------------------------------------- 1 | baseURL = "https://kernelci.org/" 2 | theme = "docsy" 3 | 4 | # -- languages -- 5 | 6 | defaultContentLanguage = "en" 7 | defaultContentLanguageInSubdir = false 8 | contentDir = "content/en" 9 | enableMissingTranslationPlaceholders = true # Useful when translating. 10 | 11 | [languages] 12 | 13 | [languages.en] 14 | languageName ="English" 15 | title = "KernelCI" 16 | description = "The upstream Linux kernel test project" 17 | 18 | # Sample additional language 19 | #[languages.fr] 20 | #languageName ="Français" 21 | #title = "KernelCI" 22 | #description = "Le projet upstream de test du noyau Linux" 23 | 24 | # -- global site parameters -- 25 | 26 | pygmentsCodeFences = true 27 | pygmentsUseClasses = false 28 | pygmentsUseClassic = false 29 | pygmentsStyle = "tango" 30 | 31 | [markup] 32 | [markup.goldmark] 33 | [markup.goldmark.renderer] 34 | unsafe = true 35 | [markup.highlight] 36 | style = "tango" 37 | 38 | [params] 39 | copyright = "KernelCI" 40 | github_repo = "https://github.com/kernelci/kernelci-project" 41 | github_branch = "main" 42 | github_subdir = "kernelci.org" 43 | 44 | [params.mermaid] 45 | enable = true 46 | 47 | # -- docsy parameters -- 48 | 49 | [params.ui] 50 | sidebar_menu_compact = false 51 | breadcrumb_disable = false 52 | sidebar_search_disable = false 53 | navbar_logo = true 54 | footer_about_disable = false 55 | 56 | [params.links] 57 | 58 | [[params.links.user]] 59 | name ="Twitter" 60 | url = "https://twitter.com/kernelci" 61 | icon = "fab fa-twitter" 62 | desc = "Follow us on Twitter to get the latest news" 63 | 64 | [[params.links.developer]] 65 | name = "GitHub" 66 | url = "https://github.com/kernelci" 67 | icon = "fab fa-github" 68 | desc = "Development takes place here!" 69 | 70 | [[params.links.developer]] 71 | name = "Discord" 72 | url = "https://discord.gg/KWbrbWEyqb" 73 | icon = "fab fa-discord" 74 | desc = "Chat with other developers!" 75 | 76 | # -- custom main menu -- 77 | 78 | [menu] 79 | [[menu.main]] 80 | identifier = "foundation" 81 | name = "Home" 82 | url = "https://kernelci.org" 83 | weight = 1 84 | 85 | [[menu.main]] 86 | identifier = "documentation" 87 | name = "Documentation" 88 | url = "/" 89 | [[menu.main]] 90 | identifier = "dashboard" 91 | name = "Dashboard" 92 | url = "https://dashboard.kernelci.org/" 93 | 94 | [[menu.main]] 95 | identifier = "blog" 96 | name = "Blog" 97 | url = "https://kernelci.org/blog/" 98 | -------------------------------------------------------------------------------- /kernelci.org/content/en/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Documentation" 3 | 4 | cascade: 5 | - type: "blog" 6 | toc_root: true 7 | _target: 8 | path: "/blog/**" 9 | - type: "docs" 10 | _target: 11 | path: "/**" 12 | --- 13 | 14 | Welcome to the KernelCI documentation website. 15 | 16 | The KernelCI mission is to ensure the quality, stability and long-term maintenance of the Linux kernel. To achieve that we are building an architecture to foster collaboration among different parties around Linux kernel testing and validation. 17 | 18 | The KernelCI architecture is complex and there are many ways to interact with it. For example, some users like upstream maintainers want to enable testing for their trees, hardware vendors may be interesting in contributing the results of tests they run on their own infra, companies or community members may be interested in contributing new features to the project code base, etc. 19 | 20 | Below, you will find starting point for the 3 main areas of interaction with the project: 21 | 22 |
23 |

24 | Using KernelCI services 25 |

26 |

Start here if you want to use KernelCI to execute tests, follow results and setup notifications. For upstream developers and/or those who care about upstream state of specific platforms.

27 |
28 | 29 |
30 |

31 | Connecting your Lab 32 |

33 |

Start here if you want to add a lab to run KernelCI tests.

34 |
35 | 36 |
37 |

38 | Contributing test results 39 |

40 |

Start here if you want 41 | to contribute your results to the KernelCI common database. KCIDB can receive tests results from any CI system.

42 |
43 | 44 |
45 |

46 | kci-dev cli 47 |

48 |

Start here if you want to interact with KernelCI instances programmatically.

49 |
50 | 51 |
52 |

53 | Contributing to KernelCI 54 |

55 |

Start here if you want to contribute to KernelCI and learn 56 | more about our technical architecture.

57 |
58 | 59 | --- 60 | If you are unsure about where to fit your need, reach out to us through our [Discord server](https://discord.gg/KWbrbWEyqb) or the mailing list at [kernelci@lists.linux.dev](mailto:kernelci@lists.linux.dev). More [contact options](https://kernelci.org/community-contact/). 61 | -------------------------------------------------------------------------------- /kernelci.org/content/en/about.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "About" 3 | date: 2024-06-10 4 | description: "Learn about the KernelCI project" 5 | weight: 1 6 | --- 7 | 8 | > KernelCI is a community-based open source distributed test automation system focused on upstream kernel development. 9 | 10 | The primary goal of KernelCI is to use an open testing philosophy to ensure the quality, stability and long-term maintenance of the Linux kernel. 11 | 12 | The Project is currently working on improving LTS kernel testing and validation; consolidation of existing testing initiatives; quality-of-life improvements to the current service; expanded compute resources; and increased pool of hardware to be tested. 13 | 14 | The Linux kernel is developed by a large, collaborative open source community working together to continuously improve the software. Conversely, Linux kernel testing has often fragmented since it is largely done in private silos with little collaboration on the testing software or methodologies. Because Linux runs on more hardware than any other operating system, it’s important to test it on the most hardware possible. KernelCI standardizes hardware testing for the Linux kernel across the broadest possible hardware. 15 | 16 | KernelCI was originally started in 2014 as a side project by a few engineers (Tyler Baker,Alan Bennett, Milo Casagrande, Kevin Hilman) who were doing the testing at home and in their spare time. A variety of hardware labs contributed to the work over time, but until now there was no sustainable structure in place for open governance and contribution, or expanded access for the developers to hardware. Today, under the Linux Foundation, companies and individuals can contribute to expanding testing and integration across more hardware than ever before. 17 | 18 | Navigate the documentation website to view the project's [mission statement](/org/#mission-statement) and 19 | [member organizations](/org/members). 20 | 21 | 22 | 23 | 24 | -------------------------------------------------------------------------------- /kernelci.org/content/en/admin/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Admin" 3 | date: 2023-09-08 4 | description: "KernelCI Administrator guide" 5 | --- 6 | 7 | This section covers topics that are useful to KernelCI system administrators. 8 | Some of it can be reused when setting up instances independent of kernelci.org. 9 | -------------------------------------------------------------------------------- /kernelci.org/content/en/admin/api.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "API" 3 | date: 2023-09-08 4 | description: "KernelCI API" 5 | --- 6 | 7 | ## Getting an admin token 8 | 9 | Some operations such as creating user accounts requires an admin user, so you 10 | need to be in the `admin` group. Then you need to get an API token to perform 11 | queries restricted to admins. Here are some sample commands to do that: 12 | 13 | ``` 14 | $ kci user whoami --indent=1 15 | { 16 | "id": "64f5ff9e8326c545a780c2a0", 17 | "email": "", 18 | "is_active": true, 19 | "is_superuser": true, 20 | "is_verified": true, 21 | "username": "", 22 | "groups": [ 23 | { 24 | "id": "6499aa9da02fef8143c1feb0", 25 | "name": "admin" 26 | } 27 | ] 28 | } 29 | $ kci user token 30 | Password: 31 | "" 32 | ``` 33 | 34 | Then you can store this token in `kernelci.toml` when running the commands 35 | that require admin permissions. Please don't use your admin token as the 36 | default one when using the regular parts of the API to avoid breaking things 37 | by mistake. 38 | 39 | ## Creating user accounts 40 | 41 | > **Note**: This is how things are done as part of the [Early 42 | > Access](/api/early-access) phase. The procedure once in production 43 | > might change if users can just sign up by themselves. 44 | 45 | First, create a random password and then use it with `kci user add` to create 46 | the account: 47 | 48 | ``` 49 | $ pwgen -y 16 -1 50 | Aeh3jah:t'ieshah 51 | $ kci user add 52 | Password: 53 | ``` 54 | 55 | If all goes well there aren't any errors and the user has been created. To 56 | double check that is the case, or to see if a user already exists or anything: 57 | 58 | ``` 59 | $ kci user find username= --indent=1 60 | [ 61 | { 62 | "id": "6526448e7d140ee220971a0e", 63 | "email": "", 64 | "is_active": true, 65 | "is_superuser": false, 66 | "is_verified": false, 67 | "username": "", 68 | "groups": [] 69 | } 70 | ] 71 | ``` 72 | 73 | Then this is a template email to send a private confirmation to the new user 74 | with the random password: 75 | 76 | ``` 77 | Subject: KernelCI API Early Access account 78 | --- 79 | Hello USERNAME, 80 | 81 | Your KernelCI API account has been created, here's your randomly 82 | generated password: 83 | 84 | PASSWORD 85 | 86 | Your personal Azure Files token is: 87 | 88 | ?sv=2022-11-02&ss=bfq&srt=sco&sp= 89 | 90 | and the associated share name is: 91 | 92 | 93 | 94 | Please take a look at the Early Access documentation page to update your API 95 | account with your own password and get started: 96 | 97 | https://docs.kernelci.org/api/early-access/ 98 | 99 | Happy beta-testing! 100 | ``` 101 | 102 | The Azure Files token is common for all the Early Access users. 103 | -------------------------------------------------------------------------------- /kernelci.org/content/en/admin/secrets.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Secrets" 3 | date: 2021-09-03 4 | description: "KernelCI project encrypted files" 5 | --- 6 | 7 | The [`secrets`](https://github.com/kernelci/kernelci-project/tree/main/secrets) 8 | directory contains encrypted files using 9 | [`git-crypt`](https://www.agwa.name/projects/git-crypt/) with credentials used 10 | by the KernelCI project. It is mostly useful to project administrators such as 11 | members of the [TSC](/org/tsc), for example to have a common place where 12 | to share passwords in a secure way. Derivative projects based on KernelCI such 13 | as private instances may reuse some of the tools and documentation provided 14 | here. 15 | 16 | 17 | ## Creating a GPG key 18 | 19 | If the user doen't already have a GPG key, they will need to create one. It 20 | may otherwise be a good idea to create a key dedicated to using git-crypt in 21 | this repository, so it may be revoked later without any side-effects on other 22 | projects or use-cases. To generate a key: 23 | 24 | ``` 25 | gpg --generate-key 26 | ``` 27 | 28 | Answer the questions interactively, it should then show something like this: 29 | 30 | ``` 31 | gpg: key E7B3A05C40D8EDC3 marked as ultimately trusted 32 | ``` 33 | 34 | with the full public key fingerprint: 35 | 36 | ``` 37 | pub rsa3072 2021-04-22 [SC] [expires: 2023-04-22] 38 | 7802ED21096B2ED7B1D4D838E7B3A05C40D8EDC3 39 | ``` 40 | 41 | This can be read again with `gpg -K`. It's then possible to [send the 42 | key](https://www.gnupg.org/gph/en/manual/x457.html) to a keyserver to make it 43 | easier for others to find it and import it with just the fingerprint rather 44 | than the full public key file. Here's how to do it with a sample keyserver and 45 | the key generated in the previous step: 46 | 47 | ``` 48 | gpg --send-keys \ 49 | --keyserver hkps://keyserver.ubuntu.com \ 50 | 7802ED21096B2ED7B1D4D838E7B3A05C40D8EDC3 51 | ``` 52 | 53 | > **Note** You may use an alternative key server, and your key hash will of 54 | course be different. 55 | 56 | ## Adding a user's GPG key 57 | 58 | The next step is to add the user's key to the repository so they can read the 59 | encrypted content. First, either get the public key file for that user and 60 | import it with `gpg --import ` or get it from a keyserver using the 61 | fingerprint using `gpg --receive-keys `. Then `gpg -K` should 62 | show the key for the user locally available. To add the user, using the 63 | fingerprint from the example in the previous step: 64 | 65 | ``` 66 | git-crypt add-gpg-user 7802ED21096B2ED7B1D4D838E7B3A05C40D8EDC3 67 | ``` 68 | 69 | This will create a git commit with the public GPG key of that user. It can 70 | then be pushed as-is, or the commit message may be edited to add the name of 71 | the user to the subject and make the history easier to read. 72 | 73 | If the key is not trusted, you can manually override this with the following 74 | command: 75 | 76 | ``` 77 | gpg --edit-key 78 | > trust 79 | > 5 80 | > y 81 | > q 82 | ``` 83 | 84 | Then run the `git-crypt add-gpg-user` again and it should work this time. 85 | 86 | 87 | ## Reading the encrypted files 88 | 89 | Users with a GPG key added to the repository can then uncrypt the files using 90 | this command: 91 | 92 | ``` 93 | git-crypt unlock 94 | ``` 95 | 96 | There are filters in the `.gitattributes` file to select which files to encrypt 97 | and which ones to keep as plain text. Essentially, all the contents of the 98 | `secrets` directory in this repository are encrypted except some documentation 99 | and utility scripts such as 100 | [`dump.py`](https://github.com/kernelci/kernelci-project/blob/main/secrets/dump.py) 101 | to dump the `passwords.toml` file. Here's what the file typically looks like: 102 | ```toml 103 | [service-name] 104 | url = "https://something.com" 105 | user = "user-name" 106 | password = "password" 107 | login_url = "https://something.com/login" 108 | email = "hello@email.com" 109 | ``` 110 | 111 | ## Making changes 112 | 113 | If you have a GPG key set up, nothing special needs to be done to contribute to 114 | the encrypted files, Git will handle this seamlessly for you. The only thing 115 | to know is that making a pull request on GitHub is not useful as the encrypted 116 | content can't be reviewed by definition. So just make a commit the usual way, 117 | maybe discuss it with others if needed, and then `git push` it. If you don't 118 | have have access rights to do so, please email `kernelci-sysadmin@groups.io` or 119 | send your patch file generated with `git format-patch` to someone who has 120 | access. 121 | -------------------------------------------------------------------------------- /kernelci.org/content/en/architecture/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "KernelCI Architecture" 3 | date: 2024-07-03 4 | description: "Learn the inner details behind the KernelCI systems" 5 | --- 6 | 7 | [![KernelCI architecture diagram](kernelci-architecture.svg)](kernelci-architecture.svg) 8 | 9 | The first thing worth noting here is that there are a number of main parts of the overall KernelCI architecture: 10 | 11 | ### [Maestro](../maestro) 12 | 13 | The middle left box of this picture shows Maestro. While Maestro is only one software system, architecturally its flow has 2 parts: (1) triggering builds and list of tests to run on each platform and (2) driving such tests. 14 | 15 | Maestro has a [pipeline-based](../maestro/pipeline) design and an [API](../maestro/api/) that allow other systems and tools to interact with it to subscribe to events (such as new build/test triggers) or send patches to be tested by the KernelCI infrastructure. 16 | 17 | ### [kci-dev](../kci-dev) 18 | 19 | [kci-dev](../kci-dev) is a stand-alone tool for Linux Kernel developers and maintainers to interact with KernelCI. There is full documentation available at [kci.dev](https://kci.dev) and a [PyPI package](https://pypi.org/project/kci-dev/). Source code is available on [GitHub](https://github.com/kernelci/kci-dev). 20 | 21 | ### [Web Dashboard](https://dashboard.kernelci.org/) 22 | 23 | A new [web dashboard](https://dashboard.kernelci.org/) has been developed to allow users to easily visualise results from KernelCI testing. Development, issues and feature requests are all being tracked on [GitHub](https://github.com/kernelci/dashboard). 24 | 25 | ### [KCIDB](../kcidb) 26 | 27 | CI systems producing their own kernel builds and running their own tests can submit results to [KCIDB](../kcidb), which is a 28 | [BigQuery](https://cloud.google.com/bigquery) database to provide a unified 29 | kernel test reporting mechanism. Please take a look at this blog post for a 30 | comprehensive description: [Introducing Common 31 | Reporting](https://kernelci.org/blog/2020/08/21/introducing-common-reporting/). 32 | 33 | ### CI Ecosystem 34 | 35 | Any CI/test system can be part of KernelCI by receiving triggers from Maestro and submitting their data to KCIDB. Receiving triggers is an optional for CI/test system, as many have their own trigger configuration already. 36 | -------------------------------------------------------------------------------- /kernelci.org/content/en/blog/.gitattributes: -------------------------------------------------------------------------------- 1 | posts/2023/rfp-ux-analysis/RFP-UX-Analysis-2023-v2.pdf filter=lfs diff=lfs merge=lfs -text 2 | -------------------------------------------------------------------------------- /kernelci.org/content/en/blog/_index.html: -------------------------------------------------------------------------------- 1 | --- 2 | date: 2021-09-13 3 | title: "Blogs" 4 | linkTitle: "Categories" 5 | description: "Top-level page for the different blog categories" 6 | --- 7 | 8 | This is the **blogs** section. It has two categories: News and Posts. 9 | 10 | Files in these directories will be listed in reverse chronological order. 11 | -------------------------------------------------------------------------------- /kernelci.org/content/en/blog/news/2019/10/29/techstartups.md: -------------------------------------------------------------------------------- 1 | --- 2 | date: 2019-10-29 3 | title: "TechStartUps: KernelCI testing platform becomes part of Linux Foundation 4 | project, now supported with funding from Microsoft, Google, Red Hat, 5 | Foundries.io, and others" 6 | linkTitle: "TechStartUps" 7 | author: KernelCI 8 | --- 9 | 10 | The [Linux Foundation](https://www.linuxfoundation.org/), the nonprofit 11 | organization enabling mass innovation through open source, today announced that 12 | KernelCI testing platform is becoming a Linux Foundation project. The project by 13 | Civil Infrastructure Platform, Foundries.io, Google, Microsoft, and Red Hat, 14 | which now join early collaborators BayLibre and Collabora to support Linux 15 | testing on the largest variety of hardware platforms. With the new level of 16 | support from tech heavyweights, KernelCI will now be able to accelerate its work 17 | to test Linux on the largest variety of hardware platforms. 18 | 19 | [Read More](https://techstartups.com/2019/10/28/kernelci-testing-platform-now-part-linux-foundation-project-now-supported-funding-microsoft-google-red-hat-foundries-io-others/) 20 | -------------------------------------------------------------------------------- /kernelci.org/content/en/blog/news/2019/10/29/zdnet.md: -------------------------------------------------------------------------------- 1 | --- 2 | date: 2019-10-29 3 | title: "ZDNet: Automated testing comes to the Linux kernel: KernelCI" 4 | linkTitle: "ZDNet" 5 | author: KernelCI 6 | --- 7 | 8 | At the recent [Linux Kernel Plumbers](https://www.linuxplumbersconf.org/) 9 | get-together in Lisbon, Portugal, one of the hottest topics was how to bring 10 | better and automated testing to the Linux kernel. There, the top Linux 11 | developers united their efforts behind one testing framework: [KernelCI 12 | ](https://kernelci.org/). Now, at [Open Source Summit Europe 13 | ](https://events19.linuxfoundation.org/events/open-source-summit-europe-2019/) 14 | in Lyon, France, to help give KernelCI the resources it needs to be successful, 15 | it became a [Linux Foundation](https://www.linuxfoundation.org/) project. 16 | 17 | [Read More](https://www.zdnet.com/article/automated-testing-comes-to-the-linux-kernel-kernelci/) 18 | -------------------------------------------------------------------------------- /kernelci.org/content/en/blog/news/2019/11/11/thenewstack.md: -------------------------------------------------------------------------------- 1 | --- 2 | date: 2019-11-11 3 | title: "The New Stack: KernelCI Joins Linux Foundation to Accelerate Linux 4 | Kernel Hardware Testing" 5 | linkTitle: "The New Stack" 6 | author: KernelCI 7 | --- 8 | 9 | Testing software can present difficulties enough on its own, but when you’re 10 | talking about the Linux kernel - that piece of software that directly interfaces 11 | with hardware - there are innumerable more complexities added to the scenario. 12 | One of those complexities, of course, is the number of devices Linux is intended 13 | to run on, from a variety of desktops, laptops and phones, to Raspberry Pis and 14 | other devices on the edge. Each device presents a new environment in which the 15 | Linux kernel needs to be tested, and that’s where [KernelCI 16 | ](https://kernelci.org/) comes into the equation. 17 | 18 | [Read More](https://thenewstack.io/kernelci-joins-linux-foundation-to-accelerate-linux-kernel-hardware-testing/) 19 | -------------------------------------------------------------------------------- /kernelci.org/content/en/blog/news/2020/08/19/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | date: 2020-08-19 3 | title: "KernelCI at Linux Plumbers" 4 | linkTitle: "Plumbers" 5 | author: KernelCI 6 | --- 7 | 8 | KernelCI will be attending [Linux Plumber’s Conference](https://www.linuxplumbersconf.org/) 9 | (LPC) online next week. We will be participating in the 10 | [Testing and Fuzzing micro-conference](https://linuxplumbersconf.org/event/7/page/80-accepted-microconferences#tf-cr), 11 | and leading a few discussion topics around automated kernel testing and 12 | reporting in the broader kernel community. 13 | 14 | {{< imgproc kernelci-blog Fit "600x300" >}}{{< /imgproc >}} 15 | 16 | Some topics we’ll be discussing: 17 | 18 | * Collecting test results from different kernel testing systems into a shared 19 | data-store for common reporting 20 | * Metrics for success: how do we know if our testing is actually useful? 21 | * Integration of kselftest, Kunit LTP into KernelCI 22 | * Other recent achievements and next steps for the project 23 | 24 | The Testing & Fuzzing micro-conference will be on Wednesday, Aug 26 from 7am to 25 | 11am (US Pacific) online, and the [full schedule is now available](https://linuxplumbersconf.org/event/7/sessions/80/#20200826). 26 | 27 | Unfortunately, passes to LPC have already [sold out](https://www.linuxplumbersconf.org/blog/2020/conference-is-sold-out-watch-live-instead/), 28 | but you can still watch the live event online. Watch the [LPC blog](https://www.linuxplumbersconf.org/blog/2020/) 29 | for more details. 30 | -------------------------------------------------------------------------------- /kernelci.org/content/en/blog/news/2020/08/19/kernelci-blog.png: -------------------------------------------------------------------------------- 1 | version https://git-lfs.github.com/spec/v1 2 | oid sha256:06972c33096396e683ba4986530a004fc1085adfbbc498dc1d42c77b1696c710 3 | size 50665 4 | -------------------------------------------------------------------------------- /kernelci.org/content/en/blog/news/_index.html: -------------------------------------------------------------------------------- 1 | --- 2 | date: 2021-09-13 3 | title: "News" 4 | linkTitle: "News" 5 | --- 6 | 7 | 8 | 9 | 10 | {{ partial "head.html" . }} 11 | 12 | 13 |
14 | {{ partial "navbar.html" . }} 15 |
16 |
17 |
18 |
19 |
20 | {{ partial "sidebar.html" . }} 21 |
22 |
23 | {{ partial "toc.html" . }} 24 |
25 |
26 | {{ with .CurrentSection.OutputFormats.Get "rss" -}} 27 | 28 | RSS 29 | 30 | {{ end -}} 31 | {{ block "main" . }}{{ end }} 32 |
33 |
34 |
35 | {{ partial "footer.html" . }} 36 |
37 | {{ partial "scripts.html" . }} 38 | 39 | 40 | -------------------------------------------------------------------------------- /kernelci.org/content/en/blog/posts/2020/05/11/featured-image-blog2.png: -------------------------------------------------------------------------------- 1 | version https://git-lfs.github.com/spec/v1 2 | oid sha256:1b62a0db0717f4ac8da2b3baac77c1b869d7580bcf1b48343688dca0c7f19b76 3 | size 30567 4 | -------------------------------------------------------------------------------- /kernelci.org/content/en/blog/posts/2020/05/11/index.html: -------------------------------------------------------------------------------- 1 | --- 2 | date: 2020-05-11 3 | title: "State of KernelCI and new blog" 4 | linkTitle: "New blog" 5 | author: KernelCI 6 | --- 7 | 8 |

KernelCI officially launched as a Linux Foundation project at the end of 9 | October 2019. Now that we’re several months into the project, it’s time to 10 | launch a blog so everyone can keep track of what’s going on.

11 | 12 | {{< imgproc featured-image-blog2 Fit "800x300" >}}{{< /imgproc >}} 13 | 14 |

To get the blog started, here’s a bit of what we’ve been up to since the 15 | project launch.

16 | 17 |

Setup / Administration

18 |

To get things off to an official start, we spent some time with the member 19 | companies getting to know each other better and establishing our basic 20 | governance structure. We now have a governing board, made up of one 21 | representative from each of the member companies: BayLibre, Civil Infrastructure 22 | Platform, Collabora, Foundries.io, Google, Microsoft and Red Hat. The governing 23 | board meets weekly for planning, discussion, budgeting decisions and to set 24 | priorities for the technical steering committee.

25 | 26 |

Recent GB accomplishments

27 |
    28 |
  • established and published project 29 | Mission & Objectives
    • 30 |
  • welcomed Long-Term Stable Initiative (LTSi) 31 | as associate member
    • 32 |
  • established collaborative development between existing CI projects under 33 | the KernelCI umbrella (kernelci.org and Red Hat CKI)
    • 34 |
35 | 36 |

Getting Technical

37 |

The technical steering committee (TSC) is where technical decisions are made 38 | and software implementation details are discussed during a weekly call as well 39 | as on our mailing list. Both the weekly call and mailing list are open to the 40 | public (details below.)

41 |

Some highlights of recent accomplishments

42 |
    43 |
  • improvements to kernelci.org frontend to view test results (previously 44 | only boot reports were available in the UI)
    • 45 |
  • building the kernel with clang (including latest version: clang-10)
    • 46 |
  • kcidb 47 |
      48 |
    • prototype of a new schema and datastore/schema using Google BigQuery
      • 49 |
    • combined results from kernelci.org and Red Hat CKI
      • 50 |
    • prototype of new email reports based on kcidb
      • 51 |
    • prototype of new web UI using kcidb based on Grafana
      • 52 |
    53 |
    • 54 |
55 |

And some active areas of development and future work ( help wanted! )

56 |
    57 |
  • increasing test coverage by enabling more test suites to run (kselftest, 58 | KUnit, LTP, xfstests, etc…)
    • 59 |
  • increased build capacity: thanks to generous donations from Google and 60 | Microsoft, we are migrating to using Kubernetes to manage our kernel build 61 | capacity using VMs from Google Cloud Platform (GCP) and Microsoft Azure. We 62 | expect to roll this out over the next month or two.
    • 63 |
  • modernization of CI/CD pipelines (e.g. container-centric tools like 64 | Tekton)
    • 65 |
  • re-factoring and upgrading codebase and tooling to python3
    • 66 |
  • improving tools to become more generic and reusable in other projects 67 | doing Kernel CI
    • 68 |
  • modernizing the UI / UX
    • 69 |
70 |

These are just a few highlights, and we have many more ideas, but things move 71 | slow since we are a very small team of active developers. If you have any 72 | interest in helping in any of these areas, please don’t hesitate to reach out.

73 | 74 |

Next steps

75 |

Building on all the great progress above, we are now gearing up for more 76 | collaboration and discussions as part of the testing and fuzzing 77 | microconference at Linux Plumbers Conference this August. The KernelCI project 78 | will be actively participating in the microconference as we aim to bring our 79 | tools to more developers, listen to feedback on some of our new ideas and 80 | directions, and make decisions on future directions.

81 | 82 |

Getting involved

83 |

Even if you cannot be involved directly at Linux Plumbers, there are many 84 | other ways to be involved in the discussion.

85 |

Follow:

86 | 95 |

Engage

96 |
    97 |
  • IRC: #kernelci on libera.chat
    • 98 |
  • Weekly technical call: Tuesdays: 16h-17h UTC
    • 99 |
  • Code: 100% open-source. All repos here: 100 | https://github.com/kernelci/
    • 101 |
102 | -------------------------------------------------------------------------------- /kernelci.org/content/en/blog/posts/2020/07/09/ci-system-usage-1024px.png: -------------------------------------------------------------------------------- 1 | version https://git-lfs.github.com/spec/v1 2 | oid sha256:d2cca7a24fc2b76e63dc8f74cf133bb77e2d5dbfb3859765b155e277acee35f7 3 | size 48116 4 | -------------------------------------------------------------------------------- /kernelci.org/content/en/blog/posts/2020/07/09/kernelci-community-survey-report-1200x325-1.png: -------------------------------------------------------------------------------- 1 | version https://git-lfs.github.com/spec/v1 2 | oid sha256:5398436704189fccadece4c01a9c828d28579207671a7eb70e59c13fd33dedff 3 | size 47611 4 | -------------------------------------------------------------------------------- /kernelci.org/content/en/blog/posts/2020/07/09/reporting-1024px.png: -------------------------------------------------------------------------------- 1 | version https://git-lfs.github.com/spec/v1 2 | oid sha256:4fcbc12aedc747c5805c4dcd8c9ff4447933e4ddae396aa0574defc177c87c18 3 | size 42283 4 | -------------------------------------------------------------------------------- /kernelci.org/content/en/blog/posts/2020/07/09/response-time-1024px.png: -------------------------------------------------------------------------------- 1 | version https://git-lfs.github.com/spec/v1 2 | oid sha256:4ec97d7eb0a64e32a78e35eb7ba65476f11951f9e73cf30b332b22bb8e07b8eb 3 | size 36798 4 | -------------------------------------------------------------------------------- /kernelci.org/content/en/blog/posts/2020/07/09/roles-distribution-1024px.png: -------------------------------------------------------------------------------- 1 | version https://git-lfs.github.com/spec/v1 2 | oid sha256:65994918cf288dca9627f60fffe77d994b1d829a1845731e587d07e1423145c0 3 | size 49954 4 | -------------------------------------------------------------------------------- /kernelci.org/content/en/blog/posts/2020/07/09/upstream-contributions-1024px.png: -------------------------------------------------------------------------------- 1 | version https://git-lfs.github.com/spec/v1 2 | oid sha256:2c9a61c169ae611fe296d0306671e51835d3b7d6066753a015d63f1cfe6a3ab4 3 | size 41350 4 | -------------------------------------------------------------------------------- /kernelci.org/content/en/blog/posts/2020/08/21/kcidb_object_relations.svg: -------------------------------------------------------------------------------- 1 | version https://git-lfs.github.com/spec/v1 2 | oid sha256:10706202ad49e1f1a3a9d40975d9090523ebd6b6719a969040ff6e5356cb10ac 3 | size 41496 4 | -------------------------------------------------------------------------------- /kernelci.org/content/en/blog/posts/2020/08/21/kcidb_object_submitting.gif: -------------------------------------------------------------------------------- 1 | version https://git-lfs.github.com/spec/v1 2 | oid sha256:d228c38367f50781ed1f15b3a161367d4d664d00addb8605a4959b251d2a1299 3 | size 66898 4 | -------------------------------------------------------------------------------- /kernelci.org/content/en/blog/posts/2020/08/21/patched_revision2.png: -------------------------------------------------------------------------------- 1 | version https://git-lfs.github.com/spec/v1 2 | oid sha256:9b4f54202432cd5a5cade293c184b6e66825184023227f1e904cf6f96a011fd0 3 | size 190820 4 | -------------------------------------------------------------------------------- /kernelci.org/content/en/blog/posts/2020/08/21/revision1.png: -------------------------------------------------------------------------------- 1 | version https://git-lfs.github.com/spec/v1 2 | oid sha256:79838e39e8c181edc119cbd8603df3e8f3f41a8f6727c41fb04528ee23c212e3 3 | size 45126 4 | -------------------------------------------------------------------------------- /kernelci.org/content/en/blog/posts/2020/09/23/index.html: -------------------------------------------------------------------------------- 1 | --- 2 | date: 2020-09-23 3 | title: "KernelCI Notes from Plumbers 2020" 4 | linkTitle: "Notes from Plumbers 2020" 5 | author: KernelCI 6 | --- 7 | 8 |

The Linux Plumbers Conference 2020 9 | was held as a virtual event this year. The online platform provided a really 10 | good experience, with talks and live discussions using 11 | Big Blue Button for the video and 12 | Rocket Chat for text-based discussions. 13 | KernelCI was mentioned many times in several micro-conferences, with two talks 14 | in Testing & Fuzzing 15 | which are now available on YouTube:

16 | 17 | 21 | 22 |

The notes below were gathered publicly from a number of attendees, they give 23 | a good insight into what was discussed. In short, while there is still a lot to 24 | be done, the KernelCI project is healthy and growing well in its role of a 25 | central CI system for the upstream Linux kernel.

26 | 27 |

Real-Time Linux

28 |

We’ve been making great progress with running LAVA jobs using the 29 | test-definitions repository from Linaro, thanks to Daniel Wagner’s help in 30 | particular. This was prompted by the discussions in the 31 | real-time micro-conference.

32 | 33 | 37 | 38 |

The next steps from a KernelCI infrastructure point of view is to be able to 39 | detect performance regressions, as these are different to binary pass/fail 40 | results. KernelCI can already handle measurements, but not yet compare them to 41 | detect regressions. Real-time getting merged upstream means it is becoming 42 | increasingly important to be able to support this.

43 | 44 |

There was also an interesting talk about determining the scheduler latency 45 | when using RT_PREEMPT and the introduction of a new tool “rtsl” to trace 46 | real-time latency. This might be an interesting area to investigate and 47 | potentially run automated tests with:

48 | 49 | 53 | 54 |

Static Analysis

55 |

The topic of static analysis and CI systems came up during the Kernel 56 | Dependability MC, and in particular, they were looking for a place to do 57 | “common reporting” in order to collect results for the various types of static 58 | analysis and checkers available. We pointed them to the KernelCI common 59 | reporting talks/BoFs.

60 | 61 |

Some static analysis can also be done by KernelCI “native” tests using the 62 | kernelci.org Cloud infrastructure via Kubernetes, which is currently only used 63 | to build kernels. This is probably where KUnit and devicetree validation will be 64 | run, but the rest still needs to be defined.

65 | 66 |

KCIDB

67 |

Fuego

68 |

Tim Bird, the main developer of Fuego at 69 | SONY, joined the KCIDB BoF and we had a good discussion. Unfortunately he had 70 | not enough time to go through to an actual submission. We got about a quarter 71 | way through converting his mock data to KCIDB.

72 | 73 |

Gentoo Kernel CI

74 |

Arisu Tachibana, maintainer of 75 | GKernelCI at Gentoo, had 76 | more time available for the KCIDB BoF and we talked through getting the data out 77 | of her system. A mockup of her data was made and successfully 78 | submitted 79 | to the KCIDB playground database setup.

80 | 81 |

Intel

82 |

Tim Orling, Yocto project 83 | architect at Intel, has expressed keen interest in KCIDB. He said he would 84 | experiment at home and will push Intel internally to participate.

85 | 86 |

LLVM/Clang

87 |

The recently added support for "LLVM=1" upstream means we can now have better 88 | support for making Clang builds. In particular, this means we’re now using all 89 | the LLVM binaries and not just clang. It also solved the issue with 90 | merge_config.sh and the default CC=gcc in the top-level Makefile.

91 | 92 |

This was enabled in kernelci.org shortly after LPC.

93 | 94 |

kselftest

95 |

The first kselftest results were produced on staging.kernelci.org during 96 | Plumbers as a collective effort. We have now started enabling them in 97 | production, so stay tuned as they should soon start appearing on 98 | kernelci.org.

99 | 100 |

Initial set of results: 101 | https://kernelci.org/test/job/next/branch/master/kernel/next-20200923/plan/kselftest/

102 | 103 |

AutoFDO

104 |

AutoFDO will hopefully get merged upstream, once it is it might be useful for 105 | CI systems to share profiling data from benchmarking runs in particular.

106 | 107 |

Building randconfig

108 |

The TuxML project carries out some research around Linux kernel builds: 109 | determining the build time, what can be optimised, which configurations are not 110 | valid… The project could benefit from the kernelci.org Cloud infrastructure to 111 | extend its build capacity while also providing more build coverage to 112 | kernelci.org. This could be done by detecting kernel configurations that don’t 113 | build or lead to problems that can’t be found with the regular defconfigs.

114 | 115 |

Using tuxmake

116 |

The goal of tuxmake is to 117 | provide a way to reproduce Linux kernel builds in a controlled environment. This 118 | is used primarily by LKFT, but it should be generic enough to cover any use-case 119 | related to building kernels. KernelCI uses its kci_build tool to generate kernel 120 | configurations and produce kernel builds with some associated meta-data. It 121 | could reuse tuxmake to avoid some duplication of effort and only implement the 122 | KernelCI-specific aspects.

123 | -------------------------------------------------------------------------------- /kernelci.org/content/en/blog/posts/2021/.gitattributes: -------------------------------------------------------------------------------- 1 | hackfests/hackfest-2-screenshot-2021-09-08-cropped.png filter=lfs diff=lfs merge=lfs -text 2 | -------------------------------------------------------------------------------- /kernelci.org/content/en/blog/posts/2021/03/16/index.html: -------------------------------------------------------------------------------- 1 | --- 2 | date: 2021-03-16 3 | title: "Looking back, looking forward" 4 | linkTitle: "Looking back, looking forward" 5 | author: KernelCI 6 | --- 7 | 8 |

2020 was the first year of the KernelCI project under the Linux Foundation 9 | and has been an interesting one. Maybe slightly less “interesting” than the rest 10 | of the world-changing events of 2020, but it’s still been an adventure. This 11 | article aims to give a quick summary of the major milestones of the first year 12 | of KernelCI project, and highlight our goals for the next year.

13 | 14 |

15 | 16 |

Highlights of the first year

17 |

The founding members spent the end of 2019 doing a formal launch and ramping 18 | up the project structure and organization. This led to 19 | our mission statement and key goals. 20 | Throughout 2020 we gave talks and led discussions at several virtual conferences 21 | such as FOSDEM, Open-Source Summit / Embedded Linux Conference (ELC). Check out 22 | our blog for more details 23 | about the talks and discussions from these events.

24 | 25 |

Community Collaboration

26 |

In the middle of 2020, we did a Community survey to get a sense for what the 27 | kernel testing and automation community was looking for. This survey has helped 28 | guide where we focus our time and resources. See our blog for an article 29 | covering the 30 | full results of the survey.

31 | 32 |

One highlight of the 2020 conference circuit was Linux Plumbers Conference 33 | (LPC). At LPC, we gave talks and held focused discussions with our target 34 | audience: kernel developers and maintainers. The full details are 35 | in a blog article covering the event, 36 | but this is where we kicked off public discussions of how to unify test results 37 | and reporting from various testing and CI efforts in the community. We’re 38 | calling this common datastore for kernel testing results kcidb. Thanks to the 39 | discussions kicked off at LPC, we’re now collecting results from several other 40 | projects such as Red Hat CKI, Google syzbot, Arm, Gentoo, and the Fuego project. 41 | Continued collaboration with these projects as well as other new ones will be a 42 | focus area for 2021.

43 | 44 |

Infrastructure

45 |

Another area of growth in 2020 was in our IT infrastructure. As you might 46 | expect, we do lots of kernel builds, and that requires lots of compute 47 | horsepower. Our build capacity had been capped by a fixed number of donated 48 | build machines. But now, thanks to the generous donations of founding members 49 | Google and Microsoft, we now have scalable cloud compute resources under Google 50 | Compute Platform (GCP) and Microsoft Azure which we manage with Kubernetes so 51 | that we can dynamically scale as our compute needs grow.

52 | 53 | 54 |

Looking forward

55 |

Kicking off 2021

56 |

The governing board kicked off our 2nd year with some project organizational 57 | matters such as budgeting and electing this year's executive committee. We are 58 | very happy to welcome Guillaume Tucker (Collabora) as the new board chair and 59 | Chris Paterson (CIP/Renesas) as the new treasurer. We also say a big thank you 60 | to outgoing chair Kevin Hilman (BayLibre) and outgoing treasurer Guy Lunardi 61 | (Collabora).

62 | 63 |

Focus areas

64 |

Data

65 |

As mentioned above, the collaboration with other testing and CI projects will 66 | remain a major focus for 2021. We want it to be easy for anyone doing kernel 67 | testing to be able to submit results to our open, centralized datastore: KCIDB. 68 | The amount of data we’re collecting is growing rapidly, so we’re also looking 69 | for help from “big data” experts to help us build the tooling to visualize and 70 | learn from all the data. Please write to us on the mailing list if you have any 71 | interest in helping here.

72 | 73 |

Infrastructure

74 |

We’ve been using Jenkins for years to manage our CI pipeline jobs, but as 75 | we’ve moved more of our infrastructure into the cloud, we’re looking at ways to 76 | migrate our CI infrastructure to a cloud-native framework such as Tekton or 77 | Jenkins-X. We’re in the early stages of exploration here, so anyone with 78 | experience here that could help guide us, we’d love to hear from you!

79 | 80 |

Data Visualization & Analysis

81 |

We’re also in the early stages of planning new dashboards for visualization 82 | and analysis of our growing data set. We’re soliciting feedback from the broader 83 | community by 84 | collecting user stories 85 | to better understand what our users want from new dashboards. In addition to 86 | making all the testing data and logs available through advanced visualization 87 | tools, we’d also like to enable analytics and deep learning on our growing data 88 | set. Once again, this is something we’d love your help on, so if you’re a big 89 | data enthusiast and want to put your skills to use to help the Linux kernel, 90 | please let us know.

91 | 92 |

Get involved!

93 |

Did you notice any themes above? We’re looking for help! We have some big 94 | ideas and plans, but we’re still a very small team and are looking for expertise 95 | in a few areas to help guide the future of the project.

96 | 97 |

Please keep in touch with what we’re up to or to get involved, you can read 98 | our blog, follow on twitter 99 | @kernelci or join our 100 | mailing list.

101 | -------------------------------------------------------------------------------- /kernelci.org/content/en/blog/posts/2021/03/16/looking-back-looking-forward.png: -------------------------------------------------------------------------------- 1 | version https://git-lfs.github.com/spec/v1 2 | oid sha256:f143ebc0cc19c785335cd317335a6bf5c275ccdd7866e706cc891ad4052b8546 3 | size 62746 4 | -------------------------------------------------------------------------------- /kernelci.org/content/en/blog/posts/2021/06/24/index.html: -------------------------------------------------------------------------------- 1 | --- 2 | date: 2021-06-24 3 | title: "The first ever KernelCI hackfest" 4 | linkTitle: "The first ever KernelCI hackfest" 5 | author: KernelCI 6 | --- 7 | 8 |

The first KernelCI test development and coverage hackfest took place from 9 | 27th May to 4th June 2021. For a total of seven days, developers from the 10 | KernelCI team, Google, and Collabora worked to improve many different aspects of 11 | KernelCI testing capabilities.

12 | 13 |

The hackfest was a community event promoted by the KernelCI team. It aimed at 14 | bringing developers and companies together to improve testing for areas of the 15 | Linux kernel they care about. Through this effort, the KernelCI team also 16 | expects to increase awareness for continuous kernel testing and validation – 17 | more hackfests will happen in the future, so stay tuned if you want to join.

18 | 19 |

The first-ever KernelCI hackfest was a success. It kicked off the work to 20 | enable kernel testing through Chromium OS, a product-specific userspace. 21 | Enabling full userspace images and real-world tests like video call simulations 22 | adds a lot of complexity to the testing process. However, the benefits are a 23 | clear win for the community. They allow a more thorough kernel testing and 24 | validation through real application use cases, which can exercise several 25 | different kernel areas at the same time in an organized manner. Generally, it is 26 | not simple for lower-level kernel test suites like kselftests or LTP to 27 | orchestrate a similar use case. 28 | 29 |

Consider video call simulation for example. Once the user starts a video 30 | call, the test can begin by measuring the time needed to set up the video feed 31 | and show it in the browser rendered with the rest of the video call website. 32 | Then, as soon as the video call is up, many other measurements can be made: 33 | camera capture latency, camera stream to network latency, memory consumption, 34 | power consumption, GPU performance, background tasks latency, and user 35 | interaction latency. These types of tests stress the kernel in unique ways, 36 | exposing problems that might otherwise go unnoticed from release to release.

37 | 38 |

The support for the Chromium OS userspace is the start of full-stack tests in 39 | KernelCI. It is still quite experimental, but the support will evolve over the 40 | next few months, opening the path for other product-specific userspaces. 41 | Increased kernel testing diversity will definitely result in catching more 42 | regressions earlier. "Keeping upstream healthy is really important to us in the 43 | Chrome OS team (and Google broadly!) since we constantly pull in stable fixes 44 | and regularly push out major kernel version upgrades to our users." said 45 | Jesse Barnes who leads the Base OS team of Chrome OS at Google.

46 | 47 |

On another 48 | front, 49 | there was progress enabling more testing for different kernel areas as well as 50 | improvements to the rootfs testing images used by KernelCI:

51 | 52 |
    53 |
  • kselftests received new tests for the futex() system call, basic semantics 54 | validation, and soft-dirty page table entry mechanism corner cases;
    • 55 |
  • improved LTP crypto tests by enabling missing kernel configs needed;
    • 56 |
  • libcamera now has its first few tests running on KernelCI;
    • 57 |
  • fs/unicode tests converted to the new Kunit mechanism;
    • 58 |
  • bootr test to check if all CPUs went online successfully;
    • 59 |
  • experimental support for including firmware files in the rootfs.
    • 60 |
61 | 62 |

The overall results were significant for only a few days of work. Kernel 63 | testing through product-specific userspace opens a whole new avenue of 64 | possibilities for KernelCI. On top of that, there was an accomplishment for many 65 | test cases and test suites, as detailed above. "It has been an amazing week and 66 | a half. We’ve achieved a lot in such a short time, in spite of a few workflow 67 | weaknesses which we’re now addressing to help further grow the KernelCI 68 | community with new developers." said Guillaume Tucker, KernelCI project lead and 69 | Senior Software Engineer at Collabora.

70 | 71 |

More hackfests will come in the future - this was only the first one. Dates 72 | are being discussed for the next hackfest to happen around the end of August, a 73 | few weeks before the Linux Plumbers Conference. The KernelCI team invites 74 | developers and companies to participate. Joining a hackfest is a great way to 75 | quickly evolve the kernel testing knowledge of your team, leading to products 76 | and services that work better with easier maintenance over time. So make sure to 77 | raise your hand and join the next time a KernelCI hackfest happens.

78 | 79 |
80 | 81 |

KernelCI is a Linux Foundation project. If you are interested in learning 82 | more or becoming a member 83 | contact us.

84 | -------------------------------------------------------------------------------- /kernelci.org/content/en/blog/posts/2021/hackfests/hackfest-2-screenshot-2021-09-08-cropped.png: -------------------------------------------------------------------------------- 1 | version https://git-lfs.github.com/spec/v1 2 | oid sha256:6f01749821c03134fb1e0a459d8ffc3c2c7589af8ca4350127f0e6b844afe837 3 | size 122265 4 | -------------------------------------------------------------------------------- /kernelci.org/content/en/blog/posts/2021/hackfests/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | date: 2021-09-20 3 | title: "KernelCI Hackfests" 4 | linkTitle: "KernelCI Hackfests" 5 | author: Guillaume Tucker 6 | description: > 7 | Lessons learned from the first two hackfests 8 | --- 9 | 10 | screenshot 11 | 12 | KernelCI hackfests span over a few days during which a number of contributors 13 | get together to focus on upstream Linux kernel testing. So far, mainly kernel 14 | and automated test system developers have been taking part in the hackfests but 15 | anyone is welcome to join. Topics mostly include extending test coverage in 16 | various ways: enabling new test suites as well as adding test cases to 17 | established frameworks such as kselftest and LTP, building additional kernel 18 | flavours, bringing up new types of hardware to be tested... 19 | 20 | There have been two hackfests to date. The current plan is to hold one 21 | every few months. Future hackfests will be announced on the [KernelCI mailing 22 | list](https://lore.kernel.org/kernelci/) as well as [LKML](https://lkml.org/) 23 | and [Twitter](https://twitter.com/kernelci). Stay tuned! 24 | 25 | 26 | ## Connecting the dots 27 | 28 | There is a large ecosystem around the Linux kernel which includes testing in 29 | many shapes and forms: kernel developers, test developers, test system 30 | developers, OEMs testing fully integrated products... All these teams of 31 | people don't necessarily interact with each other very much outside of their 32 | organisations, and kernel developers aren't necessarily in the habit of writing 33 | tests as part of their daily work. 34 | 35 | Events such as the KernelCI hackfests give a chance for people from these 36 | different areas to work together on solving common issues and keep the 37 | ecosystem healthy. It also helps with shifting the upstream Linux kernel 38 | development culture towards a more test-driven workflow, to bring mainline 39 | Linux closer to the real world where it is actually being used. 40 | 41 | Let's consider a plausible hackfest story. A first participant writes a new 42 | test, say in kselftest. A second participant enables the test to run in 43 | KernelCI, which fails in some cases and a kernel bug is found. A third 44 | participant makes a fix for the bug, which can then be tested directly in 45 | KernelCI to confirm it works as expected. This may even happen on the [staging 46 | instance](/instances/staging/) before the patches for the test and the fix 47 | are sent to any mailing list, in which case the fix would get a `Tested-by: 48 | "kernelci.org bot" ` trailer from the start. This scenario 49 | also relies on some hardware previously made available in test labs by other 50 | people, putting together efforts from at least four different participants. 51 | 52 | 53 | ## Timeline 54 | 55 | Here's a summary of the first two hackfests: 56 | 57 | ### Hackfest #1 - 27th May to 4th June 2021 58 | 59 | * Workboard: https://github.com/orgs/kernelci/projects/3 60 | * Participans 61 | * Several kernel developers from [Google Chrome 62 | OS](https://www.google.com/intl/en_uk/chromebook/chrome-os/) 63 | * Several kernel developers from [Collabora](https://collabora.com) 64 | * A few members of the core KernelCI team 65 | * Achievements 66 | * New KernelCI instance for Chrome OS on https://chromeos.kernelci.org 67 | * Added support for building Chrome OS configs on top of mainline 68 | * Enabled clang-13 builds for Chrome OS and main KernelCI builds 69 | * New test suite for libcamera enabled on https://linux.kernelci.org 70 | * Enabled LTP crypto tests with extra kernel config fragment 71 | * Several patches were also sent to extend kselftest and KUnit coverage in 72 | the kernel tree 73 | 74 | ### Hackfest #2 - 6th to 10th September 2021 75 | 76 | * Workboard: https://github.com/orgs/kernelci/projects/5 77 | * Participants 78 | * More members of the [TSC](/org/tsc/) took part than first hackfest 79 | * New contributor: Denis Efremov (floppy disk kernel maintainer) 80 | * Arisu from [Civil Infrastructure Platform](https://www.cip-project.org/) 81 | (CIP) / [Cybertrust Japan](https://www.cybertrust.co.jp/english/) 82 | * Chris from [Civil Infrastructure Platform](https://www.cip-project.org/) 83 | (CIP) / [Renesas](https://www.renesas.com/eu/en) 84 | * Nikolai from [Red Hat's CKI](https://cki-project.org/) 85 | * Several KernelCI developers from [Collabora](https://collabora.com) 86 | * Achievements 87 | * New Docker images and initial steps for running 88 | [`cvehound`](https://github.com/evdenis/cvehound) 89 | * On-going progress with Chrome OS tests using QEMU and hardware in LAVA 90 | * Support for CIP kernel configs 91 | * Initial work to enable CIP Core images (Debian based) 92 | * Set up redirect from [cip.kernelci.org](https://cip.kernelci.org) to the 93 | web dashboard page with [CIP jobs](https://linux.kernelci.org/job/cip/) 94 | * Support for `xilinx-zcu102` device 95 | * Initial work to enable IEC cybersecurity tests 96 | * Initial work to enable kselftest livepatch 97 | * Most of the content from https://foundation.kernelci.org replicated on the 98 | new [kernelci.org](https://kernelci.org) static site 99 | * Started adding support for including kernel firmware files in test jobs 100 | * Many various bug fixes and improvements in the KernelCI core code 101 | 102 | 103 | ## Lessons Learned 104 | 105 | ### What went well 106 | 107 | * There were several new contributors. The hackfest is a great way to get 108 | people started with KernelCI. 109 | * Hackfest #2 showed more diversity with a wider representation from the 110 | ecosystem. 111 | * There were many improvements in various areas (bug fixes, documentation) 112 | which is a sign of a healthy project. 113 | * The workflow based on GitHub and the Big Blue Button platform appear to have 114 | been easily adopted by the participants. 115 | 116 | ### What needs to be improved 117 | 118 | * Having more kernel maintainers involved would help with setting priorities 119 | and ojectives for KernelCI in accordance with kernel developers' needs. 120 | * A hackfest every 3 months may be a bit too often, or maybe some could be 121 | shorter or have a more particular theme. 122 | * Changes can take a long time to get merged. The main limitation seems to be 123 | the number of people available to do code reviews and drive discussions. 124 | * KernelCI has been focusing on running more tests for over a year (kselftest, 125 | LTP, IGT…). Now the core architecture needs to be improved to scale better. 126 | 127 | 128 | ## Next hackfest 129 | 130 | The actual dates haven't been confirmed yet, but with the current 3-month 131 | frequency the next hackfest should be taking place early December 2021. A 132 | proposed theme could be "KernelCI for newbies", with a selection of tasks well 133 | suited for first-time contributors and documentation improved in that area 134 | prior to the hackfest. As always, suggestions are always welcome so please do 135 | get in touch if you have any. 136 | 137 | See you there! 138 | -------------------------------------------------------------------------------- /kernelci.org/content/en/blog/posts/2022/rfp-sysadmin/RFP-Sysadmin-Maintenance-2022-v3.pdf: -------------------------------------------------------------------------------- 1 | version https://git-lfs.github.com/spec/v1 2 | oid sha256:f9342d1ed755bc93d7757dfebee3dcb0e144d83655eb6bc533c737e73c94bac1 3 | size 110247 4 | -------------------------------------------------------------------------------- /kernelci.org/content/en/blog/posts/2022/rfp-sysadmin/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | date: 2022-06-27 3 | title: "Request for Proposals: Sysadmin Maintenance 2022" 4 | linkTitle: "RFP: Sysadmin 2022" 5 | author: Guillaume Tucker 6 | description: > 7 | Request for Proposal for KernelCI sysadmin maintenance 8 | --- 9 | 10 | ## Summary 11 | 12 | The KernelCI project relies on a number of web services which need constant 13 | maintenance. These include databases, automation tools and web dashboards for 14 | several instances. Some are hosted on dedicated virtual machines (VMs), others 15 | in the cloud. This Request for Proposals seeks to extend the current team with 16 | dedicated sysadmins to ensure the maintenance of these services is being 17 | carried out to guarantee a good quality of service. Additionally, some 18 | improvements can be made to reduce the maintenance burden. 19 | 20 | ## Budget 21 | 22 | We’re expecting quotations for this work package to range between 15,000 and 23 | 30,000 USD depending on the contents of the proposal and for a period of six 24 | months. Longer sysadmin time available and extra improvements can justify a 25 | higher price. Payments would be made via the Linux Foundation using the 26 | project’s own budget. 27 | 28 | ## Sending proposals 29 | 30 | Please take a look at the full 31 | [RFP-Sysadmin-Maintenance-2022-v3.pdf](RFP-Sysadmin-Maintenance-2022-v3.pdf) 32 | document for all the details. Proposals should be sent by email directly to the 33 | [project members](mailto:kernelci-members@groups.io). 34 | 35 | The deadline for responding to this RFP is **8th August 2022**, six weeks after 36 | it has been made public. Then the KernelCI Advisory Board of Members will vote 37 | on the **24th August 2022**. Exact dates might be subject to change in case of 38 | a major practical issue or unavailability of voting members. 39 | -------------------------------------------------------------------------------- /kernelci.org/content/en/blog/posts/2022/sysadmin-onboard/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | date: 2022-09-28 3 | title: "Now KernelCI has a dedicated SysAdmin!" 4 | linkTitle: "Now KernelCI has a dedicated SysAdmin!" 5 | author: Gustavo Padovan 6 | description: > 7 | The KernelCI.org project welcomes Vince Hillier as SysAdmin 8 | --- 9 | 10 | Recently, we posted about the [Request For 11 | Proposals](/blog/posts/2022/rfp-sysadmin/) to undertake SysAdmin tasks for 12 | KernelCI.org. That process is now complete, and we are delighted to announce 13 | that the KernelCI advisory board hired Vince Hillier from Revenni Inc to 14 | conduct the work. 15 | 16 | Vince will work together with the Technical Steering Committee 17 | ([TSC](/org/tsc/)) to maintain and improve the current project 18 | infrastructure. As KernelCI.org scales with more kernels being built and more 19 | tests being run, we definitely need help to keep our systems stable and up to 20 | date. 21 | 22 | The KernelCI project relies on a number of web services which need constant 23 | maintenance. These include databases, automation tools and web dashboards for 24 | several [instances](/instances/). Some are hosted on dedicated virtual 25 | machines (VMs), others in the cloud. 26 | -------------------------------------------------------------------------------- /kernelci.org/content/en/blog/posts/2023/api-early-access/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | date: 2023-09-04 3 | title: "KernelCI API Early Access" 4 | linkTitle: "KernelCI API Early Access" 5 | author: Guillaume Tucker 6 | description: > 7 | Early Access phase of the KernelCI API & Pipeline transition timeline 8 | --- 9 | 10 | ## Free for all 11 | 12 | Today is the beginning of the Early Access phase for the new KernelCI API. As 13 | explained briefly in the [previous blog 14 | post](https://kernelci.org/blog/posts/2023/api-timeline/), this is to give 15 | everyone a chance to create a user account and start using the API for 16 | beta-testing purposes. There's now an [Early 17 | Access](https://docs.kernelci.org/api/early-access/) documentation page with a 18 | quick guide to get started, so please go take a look there and start taking 19 | part. 20 | 21 | ## A work in progress 22 | 23 | Although the fundamental principles of the API & Pipeline have now settled a 24 | bit, it is still under active development. In particular, we're expecting to 25 | see a fair amount of changes in these areas: 26 | 27 | ### `kci` command line tool 28 | 29 | It's still very new and only provides some basic features, so now it needs some 30 | proper design. For example, new commands should be added and it might become 31 | more human-readable with things like `kci find node` rather than `kci node 32 | find`. 33 | 34 | ### Build and test coverage 35 | 36 | This can only grow as right now there's only KUnit, one x86 build and one QEMU 37 | smoke test run for each kernel revision (and only from mainline). Starting to 38 | scale this up will help tackle the main bottlenecks and performance issues in 39 | the infrastructure before reaching production quality. 40 | 41 | ### Documentation 42 | 43 | Yes, now that things are shaping up we should also be taking good care of the 44 | overall documentation and general ease of use of the project. This should also 45 | encompass things such as moderation rules to ensure continuity of the project. 46 | 47 | ## A two-way process 48 | 49 | This system is made for you, all the members of the wider Linux kernel 50 | ecosystem. So while there's a small but growing team of developers still 51 | typing away all the code needed to make it happen, we need your feedback to 52 | help shape things up in such a way that it actually delivers on its 53 | expectations. 54 | 55 | Please experiment as much as you like and share your stories, thoughts and 56 | questions via the project's usual communication channels. Also feel free to 57 | create issues on GitHub and send pull requests of course. 58 | 59 | **Happy beta-testing!** 60 | -------------------------------------------------------------------------------- /kernelci.org/content/en/blog/posts/2023/api-timeline/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | date: 2023-07-28 3 | title: "API Transition Timeline" 4 | linkTitle: "API Transition Timeline" 5 | author: Guillaume Tucker 6 | description: > 7 | Timeline for transitioning to the new KernelCI API & Pipeline 8 | --- 9 | 10 | Once upon a time, on a Thursday afternoon somewhere in Italy, a KernelCI 11 | backend API was created: 12 | 13 | ``` 14 | commit 08c9b0879ebe81463e124308192670c0e7447e0b 15 | Author: Milo Casagrande 16 | Date: Thu Feb 20 16:10:41 2014 +0100 17 | 18 | First commit. 19 | ``` 20 | 21 | As you can see, it was nearly 10 years ago. How much does that represent in 22 | the modern software world? Of course, it depends. The Linux kernel is much 23 | older, still written in C and still going strong. But in most cases, including 24 | this particular one, it means a whole new world. The old API was written in 25 | Python 2.7 which stopped being maintained as a language on 1st January 2020. 26 | We could have just rewritten it in Python 3, which was the initial thought. 27 | But in the meantime, KernelCI was also growing as a project. It wasn't just 28 | about building ARM kernels and doing boot testing on embedded dev boards any 29 | more. It had become a Linux Foundation project aiming to test the whole 30 | upstream kernel. 31 | 32 | ## What is this new API? 33 | 34 | Following this move, an increasing number of people became interested as it got 35 | under the spotlight. That is when we started to realise that the architecture 36 | needed to fundamentally evolve in order to match the scale of the new mission 37 | it had been assigned. The Linux kernel is a vast and complex open-source 38 | project with a unique ecosystem. As such, it requires some unique tooling too. 39 | We all know that [Git](https://git-scm.com/) was initially created out of a 40 | need to manage all the kernel patches. Now KernelCI needs an automated testing 41 | tool tailor-made to its unique requirements - and that's why we're finally 42 | launching the new API & Pipeline. 43 | 44 | It comes with lots of improvements and it's still a work-in-progress. We'll 45 | keep publishing blog posts and update the documentation as things evolve over 46 | the next few months. Right now we have a pipeline that can monitor Git 47 | repositories for new revisions, take a snapshot of the kernel source tree in a 48 | tarball, run KUnit with it as well as an x86 kernel build and smoke test it in 49 | QEMU. It can then also send a summary email and detect regressions. That's 50 | basically enough to prove we have a workable system. Nothing too 51 | groundbreaking there, you might think. So, what's all the fuss about? 52 | 53 | In a nutshell: a Pub/Sub interface to orchestrate distributed client-side 54 | services that can be run anywhere. You could have your own too at home. Also: 55 | user accounts so you can keep your own personal test data there, an abstraction 56 | for runtime environments so jobs can be run seamlessly in Docker, Kubernetes, a 57 | local shell, LAVA, [insert your own system here]... a new `kci` command line 58 | tool to rule them all and a unified Node schema to contain all the test data 59 | (revision, build, runtime test, regression...) in a tree. But again, we'll go 60 | through all that later in more detail. It's all based on requirements gathered 61 | from the community over the past few years. 62 | 63 | ## Timeline 64 | 65 | The main message in this blog post is the timeline for retiring the old system 66 | and getting the new API in production. Here's the proposal: 67 | 68 | Early Access 69 | : Monday 4th September 2023 70 | 71 | Production Deployment 72 | : Monday 4th December 2023 73 | 74 | Legacy System Deprecation 75 | : Monday 4th March 2024 76 | 77 | Legacy System Sunset 78 | : Monday 4th November 2024 79 | 80 | It only takes four Monday-the-Forth milestones to get through all this. Here's 81 | what they mean: 82 | 83 | ### Early Access 84 | 85 | This is when a new API & Pipeline instance becomes available to let the public 86 | experiment with it. It can be seen as some form of beta-testing. It will be 87 | deployed in the Cloud to evaluate how a real production instance would behave, 88 | but it's only kept online as a best effort. There should be frequent updates 89 | as the code evolves, probably at least weekly and at most daily. Only changes 90 | that made it through early testing on the staging instance should be deployed 91 | so it's meant to be reasonably stable. 92 | 93 | ### Production Deployment 94 | 95 | The plan is to build upon the experience learned from the Early Access 96 | deployment to prepare a persistent instance that would eventually become the 97 | production one. Data should be carefully kept and backed up, changes in the 98 | database schema should go through managed migrations and the API code should be 99 | deployed from tagged releases. As soon as this has become reliable enough we 100 | might shut down the Early Access instance since it should have become redundant 101 | by then. 102 | 103 | ### Legacy System Deprecation 104 | 105 | In other words, this is when the new API & Pipeline production instance becomes 106 | the official main KernelCI instance. We'll first be going through a transition 107 | phase to ramp up the build and test coverage on the new API while equally 108 | reducing the load on the legacy system to avoid overloading the shared 109 | infrastructure. Ideally, coverage should have reached 80% on the new API and 110 | 20% on the old one by this date. 111 | 112 | ### Legacy System Sunset 113 | 114 | After being deprecated, the legacy system will keep running with a bare minimal 115 | amount of coverage just to facilitate the transition for users who depended the 116 | most on it. It will be definitely shut down and the data will be archived when 117 | finally reaching the Sunset milestone. 118 | 119 | ## Stay tuned 120 | 121 | These dates have been identified as realistic targets for having the new API 122 | rolled out and retiring the old one with a transition in between. We'll be 123 | aiming to have the new API in place _by_ these dates and conversely retire the 124 | legacy system _no sooner than_ announced here. 125 | 126 | In the meantime, we'll be posting updates as these milestones get reached or if 127 | any alterations need to be managed. We'll also clarify how to use the API and 128 | exactly what features become available alongside the main 129 | [documentation](/api). Please share with us any feedback you may have, if 130 | you need some clarifications or to raise any concerns. The best way to do this 131 | is via the [mailing list](mailto:kernelci@lists.linux.dev) as always. Stay 132 | tuned! 133 | -------------------------------------------------------------------------------- /kernelci.org/content/en/blog/posts/2023/fosdem-2023/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | date: 2023-01-27 3 | title: "KernelCI at FOSDEM 2023" 4 | linkTitle: "KernelCI at FOSDEM 2023" 5 | author: Guy Lunardi 6 | description: > 7 | The KernelCI.org project participation at FOSDEM 2023 8 | --- 9 | 10 | Taking place February 4th and 5th, FOSDEM is a fantastic event organised "by the community for the community" in Brussels, Belgium, Europe. FOSDEM provides Open Source communities a place to meet in person. 11 | 12 | The KernelCI initiative is delighted to be present at FOSDEM 2023. 13 | 14 | Testing is recognized by all to be critically important for Open Source communities at large, and not enough is being done. The KernelCI initiative (a Linux Foundation project) intends to change that. 15 | 16 | During the weekend of FOSDEM 2023, please keep testing in mind throughout the conversations you will be having with peers and members of the community. 17 | 18 | Remind yourself and your interlocutors of the importance of testing and the existence of the KernelCI initiative. 19 | 20 | ## Find out more about KernelCI 21 | 22 | Mission statement: https://kernelci.org/org/ 23 | 24 | Interested to see your tests ran by KernelCI natively? 25 | Here is how to [get started](https://docs.kernelci.org/tests/howto/) with KernelCI. 26 | 27 | You already have your own automated execution of tests and would be interested/willing to contribute your results? Please see the [KCIDB submitter guide](https://github.com/kernelci/kcidb/blob/main/doc/submitter_guide.md). 28 | 29 | You can find the [catalog](https://github.com/kernelci/kcidb/blob/main/tests.yaml) (yaml file) of the tests integrated today here. Some of the most notable test suites reporting today: bpf, kselftest, ltp, perftool, podman, Redhat’s test suites, stress-ng, syzkaller, xfstests, and many more. 30 | 31 | If you would like some help, please reach out to the KernelCI community: 32 | * Mailing list: http://lore.kernel.org/kernelci/ 33 | * Code: http://github.com/kernelci 34 | * Twitter: https://twitter.com/kernelci 35 | 36 | Members of the KernelCI Advisory Board (AB) and Technical Steering Committee (TSC) will be present in-person at FOSDEM 2023. Many will be in the [Testing and Automation devroom](https://fosdem.org/2023/schedule/track/testing_and_automation/) (Sunday morning in room UB4.132). 37 | 38 | Looking forward to meeting as many as possible in Brussels, February 4th and 5th 2023. 39 | 40 | ## KernelCI related talks at FOSDEM 2023 41 | 42 | [A case for DAG databases Correlating revision history with CI results](https://fosdem.org/2023/schedule/event/graph_case_for_dag/) 43 | * Track: Graph Systems and Algorithms devroom 44 | * Room: K.4.601 45 | * Day: Saturday 46 | * Start: 12:00 47 | 48 | [Growing a lab for automated upstream testing: challenges and lessons learned](https://fosdem.org/2023/schedule/event/growing_testing_lab/) 49 | * Track: Testing and Automation devroom 50 | * Room: UB4.132 51 | * Day: Sunday 52 | * Start: 09:30 53 | 54 | [Rethinking device support for the long-term](https://fosdem.org/2023/schedule/event/device_support/) 55 | * Track: Kernel devroom 56 | * Room: UA2.220 (Guillissen) 57 | * Day: Sunday 58 | * Start: 16:30 59 | -------------------------------------------------------------------------------- /kernelci.org/content/en/blog/posts/2023/rfp-ux-analysis/RFP-UX-Analysis-2023-v2.pdf: -------------------------------------------------------------------------------- 1 | version https://git-lfs.github.com/spec/v1 2 | oid sha256:5788872e556a169ae29b0c8309150defe2fa775558929cf193f90b1d709ef2d6 3 | size 112574 4 | -------------------------------------------------------------------------------- /kernelci.org/content/en/blog/posts/2023/rfp-ux-analysis/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | date: 2023-05-29 3 | title: "Request for Proposals: UX Analysis 2023" 4 | linkTitle: "RFP: UX Analysis 2023" 5 | author: Guillaume Tucker 6 | description: > 7 | Request for Proposal for KernelCI User Experience Analysis 8 | --- 9 | 10 | The KernelCI project runs thousands of Linux kernel tests every day, generating 11 | a huge amount of data to help the community identify issues and trends. One way 12 | to communicate all this is through a bespoke web application that truly 13 | embodies the kernel community’s use cases. This Request For Proposals (RFP) 14 | aims to be an initial investigation to understand how the User Experience (UX) 15 | of the Web Dashboard could look like based on a set of user stories compiled by 16 | the KernelCI team. 17 | 18 | ## Budget 19 | 20 | We're expecting vendors to submit a fixed-price proposal showing the total 21 | costs for the different phases they plan for the project. Optional or extra 22 | phases can be included as well. The vendors have autonomy to propose a process 23 | for the iterative feedback roadmap. Payments would be made by the Linux 24 | Foundation using the project’s own budget. 25 | 26 | ## Sending proposals 27 | 28 | Please take a look at the full 29 | [RFP-UX-Analysis-2023-v2.pdf](RFP-UX-Analysis-2023-v2.pdf) 30 | document for all the details. Proposals should be sent by email directly to the 31 | [project members](mailto:kernelci-members@groups.io). 32 | 33 | The deadline for responding to this RFP is **10th July 2023**, six weeks after 34 | it has been made public. Then the KernelCI Advisory Board of Members will vote 35 | on the **24th July 2023**. Exact dates might be subject to change in case of a 36 | major practical issue or unavailability of voting members. 37 | 38 | > **Edit**: Following a surge in last-minute queries, the timeline has now been 39 | > extended. The new deadline for submitting proposals is **24th July 2023** 40 | > and the advisory board is planning to hold a vote on **9th August 2023**. 41 | -------------------------------------------------------------------------------- /kernelci.org/content/en/blog/posts/2023/ux-analysis/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | date: 2023-12-04 3 | title: "UX Analysis" 4 | linkTitle: "UX Analysis" 5 | author: Guillaume Tucker 6 | description: > 7 | KernelCI User Experience Analysis 8 | --- 9 | 10 | Following the [UX Analysis RFP](/blog/posts/2023/rfp-ux-analysis/) we shared a 11 | few months ago, we're now delighted to announce that the KernelCI Advisory 12 | Board has accepted a proposal. First of all, we're grateful to have received 13 | such a series of high-quality proposals. Many thanks once again to all the 14 | submitters for your interest in the project. 15 | 16 | After carefully considering all the options with the board and some TSC 17 | members, the vote came out in favour of 18 | [ProFUSION](https://profusion.mobi/index-en.html). Congratulations! We're 19 | looking forward to the next milestones, in fact the work has already started. 20 | 21 | ## Milestones 22 | 23 | The UX Analysis project is broken down into three milestones with four weeks 24 | assigned to each, so a total of twelve weeks. Some breaks will also be 25 | scheduled during this time so the calendar end date is likely to be in March 26 | 2024. 27 | 28 | ### M1: Result of interviews 29 | 30 | Some interviews will be carried out with various stakeholders to help refine 31 | user stories and start modelling the user experience and some design aspects. 32 | 33 | ### M2: First UX design proposal 34 | 35 | A first interactive prototype will then be created and made available for 36 | members of the public to evaluate and provide feedback. 37 | 38 | ### M3: Final UX design proposal 39 | 40 | Based on the feedback and outcome of the first two milestones, the last part is 41 | about creating high-level specifications of the web dashboard design suitable 42 | for the implementation phase. 43 | -------------------------------------------------------------------------------- /kernelci.org/content/en/blog/posts/2024/strategic-updates/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | date: 2024-04-08 3 | title: "Strategic updates from the KernelCI project" 4 | linkTitle: "Strategic updates from the KernelCI project" 5 | author: Gustavo Padovan 6 | description: > 7 | Check out our strategic overview of the steps we have taken towards KernelCI mission over the past few months. 8 | --- 9 | 10 | The KernelCI project continues on its mission to ensure the quality, stability and long-term maintenance of the Linux kernel. That means supporting the community (especially maintainers) to not just run their code in a Continuous Integration (CI) system, but also deliver relevant, high confidence results and reports. In this post, we will give you a strategic overview of the steps we have taken towards our mission over the past few months. 11 | 12 | ## Enabling new infrastructure to run tests 13 | 14 | Our legacy system has shown its age and it has been failing to meet the growing testing needs of the community. It is a quite limited, unstable python2 project that focuses on embedded hardware. We continue on the journey to put in place our new infrastructure, so we can finally move away from the legacy KernelCI system. 15 | 16 | We bring good news! The new core service for running tests is already in place, but still going through a stabilization phase. So, the team is ramping up the number of tests slowly to deal with issues that arise especially when it comes to the quality of the testing KernelCI provides. We do not want to repeat past mistakes with results that can't really be trusted, so our focus right now is on quality rather than quantity. The team is iterating quickly on that process to enable open, wide adoption in the coming months. 17 | 18 | In our new KernelCI infrastructure, we already have support to run tests in labs (through [LAVA](https://www.lavasoftware.org/) only at the moment), Docker containers, Kubernetes and natively. Adding new labs or test environments should be relatively straightforward. Then, as we add more test environments, we are also laying down the foundation for integration with other CI systems across the community so we can share kernel builds and offer test environments. 19 | 20 | As we shared [before](https://kernelci.org/blog/posts/2023/api-early-access/), the new infrastructure exposes an API for users to create accounts, query results and even drive tests themselves. At the moment, we are focusing on enabling our own pipeline there, so we can shut down the legacy system. But anyone is welcome to request a user account and try it out. 21 | 22 | Another initiative from the KernelCI community is the [GitLab CI support in the mainline](https://lore.kernel.org/lkml/20240228225527.1052240-1-helen.koike@collabora.com/) kernel. Here, the goal is to offer maintainers a CI environment that they can manage themselves. With time, KernelCI API can be leveraged to provide a backend for builds and test runs for repositories using GitLab CI. 23 | 24 | ## Trusting tests results and reports 25 | 26 | On one end, we are stabilizing our new infrastructure to run the tests. On the other end, we are looking into improving the quality of the reports KernelCI sends out, so maintainers and developers can actually trust them. Given the huge amount of data coming out of test systems and bots today, we must invest in improving the delivery of the results, or else, KernelCI will be contributing to increasing the maintainer burnout rather than helping solve it. That means improving the quality and confidence of the data, so maintainers and developers only receive reports packed with relevant information and no noise or false-positives. 27 | 28 | At the time of this writing, we have a handful of trees enabled, boot testing and a few tests enabled (including kselftest support) in our new test infrastructure. That setup is enabling the team to triage **ALL** the results to identify infrastructure failures and test patterns in general (flakiness, config issue, intermittent issues, etc). There is a significant investment to develop better tests together with the community (like the [device tree probe kselftest](https://www.collabora.com/news-and-blog/blog/2023/12/11/a-new-kselftest-for-verifying-driver-probe-of-devicetree-based-platforms/)) that is improving the quality of the results compared to what exists in our legacy system. 29 | 30 | As part of the effort, we are developing a layer for **post-processing the test results** in [KCIDB](https://github.com/kernelci/kcidb) - the KernelCI database to collect test results from the entire Linux kernel test ecosystem. The work in this area is at proof-of-concept level, but it is already enabling the team to evaluate the results coming from our new infrastructure. The post-processing layer should be a key part of the feedback loop with the community. The goal is to increase [automation in triaging the results](https://www.collabora.com/news-and-blog/blog/2024/03/14/automatic-regression-handling-and-reporting-for-the-linux-kernel/), saving precious time from kernel maintainers. Also, because KCIDB collects data from various CI systems, the post-processing of test results can be enabled for more systems than just KernelCI. 31 | 32 | On top of that, the KernelCI team is redesigning the Web Dashboard UX to enable rich visualization of all that data for the entire community. A public request for feedback on UX should go out in the coming weeks. 33 | 34 | ## It's all about engaging the community in testing 35 | 36 | Solving CI needs for the Linux kernel community is not just a technical challenge. It is in big part a community engagement challenge too. The KernelCI project has a strong focus on engaging the community in testing processes. With our new infrastructure coming into place, we are ready to give a new spin to our Community Engagement initiative. 37 | 38 | For that, we are forming a Community Engagement Working Group (WG). The WG will focus on connecting with maintainers to discuss and implement improvements in test quality for their subsystems and also act as a feedback recipient for improvements in our post-processing of the test results. The Community Engagement WG will be led by Shuah Khan, kernel maintainer & Linux 39 | Fellow at The Linux Foundation. 40 | 41 | A dedicated [announcement](https://lore.kernel.org/kernelci/bf81be70-61ec-4169-b66a-5c3136869107@gmail.com/T/#u) of the Community Engagement WG was sent to the KernelCI mailing list. If you are interested in participating, raise your hand! 42 | 43 | ## Where are we going from here? 44 | 45 | As you can see, a lot is going on in KernelCI at the moment. The team is iterating quickly on the development of the new infrastructure, so we will be engaging with new maintainers and developers every month from now on, bringing them to the new infra and pushing the system limit further. If you are a maintainer and want to bring your tests to KernelCI please send us an email at [kernelci@lists.linux.dev](mailto:kernelci@lists.linux.dev). 46 | 47 | That's all for now! Stay tuned for updates on topics discussed in this article. Likewise, as the new infrastructure stabilizes, expect a significant amount of documentation updates too. 48 | 49 | We thank all KernelCI [member organizations](https://docs.kernelci.org/org/members/) and developer community who have been investing in the project over the years. It is only because of the continued support from our community that we are making the legacy system a past story! -------------------------------------------------------------------------------- /kernelci.org/content/en/blog/posts/2024/tsc-updates/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | date: 2024-04-01 3 | title: "Exciting KernelCI TSC updates" 4 | linkTitle: "Exciting KernelCI TSC updates" 5 | author: Gustavo Padovan 6 | description: > 7 | Shuah Khan joins the TSC, and Nikolai Kondrashov elected new TSC Chair 8 | --- 9 | 10 | During our last TSC meeting, on March 14th, we had two votes that brought new winds to our community: 11 | 12 | **Shuah Khan joins the TSC** 13 | 14 | Shuah, Kernel Maintainer & Linux Fellow at The Linux Foundation, has been elected a new member of the TSC. We believe Shuah's experience will help the KernelCI project expand its kernel community engagement efforts, taking testing and CI to more parts of the upstream kernel. Welcome, Shuah! 15 | 16 | **Nikolai Kondrashov elected as the new TSC Chair** 17 | 18 | Nikolai has been a longstanding contributor under the KernelCI umbrella and the person behind KCIDB. At Red Hat he also contributes to kernel integration technology. His knowledge around the problems KernelCI needs to solve will help the project greatly. His role will be effective on April 1st. All the best to Nikolai in his new role! 19 | 20 | While at it, we thank Guillaume for his tenure as TSC Chair of the project! 21 | 22 | The detail of the motions which were voted can be found on the TSC 23 | [documentation](https://docs.kernelci.org/org/tsc/votes/#2024-03-14). -------------------------------------------------------------------------------- /kernelci.org/content/en/blog/posts/_index.html: -------------------------------------------------------------------------------- 1 | --- 2 | date: 2021-09-13 3 | title: "Posts" 4 | linkTitle: "Posts" 5 | --- 6 | 7 | 8 | 9 | 10 | {{ partial "head.html" . }} 11 | 12 | 13 |
14 | {{ partial "navbar.html" . }} 15 |
16 |
17 |
18 |
19 |
20 | {{ partial "sidebar.html" . }} 21 |
22 |
23 | {{ partial "toc.html" . }} 24 |
25 |
26 | {{ with .CurrentSection.OutputFormats.Get "rss" -}} 27 | 28 | RSS 29 | 30 | {{ end -}} 31 | {{ block "main" . }}{{ end }} 32 |
33 |
34 |
35 | {{ partial "footer.html" . }} 36 |
37 | {{ partial "scripts.html" . }} 38 | 39 | 40 | -------------------------------------------------------------------------------- /kernelci.org/content/en/contacts.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Contact us" 3 | date: 2024-09-12 4 | description: "How to contact us" 5 | weight: 1 6 | --- 7 | 8 | > KernelCI community contacts are available on the [KernelCI website](https://kernelci.org/community-contact/). 9 | -------------------------------------------------------------------------------- /kernelci.org/content/en/faq.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "FAQ" 3 | date: 2021-03-30T22:02:52Z 4 | description: Frequently asked questions 5 | --- 6 | 7 | **Q: How can I add a kernel branch to kernelci.org?** 8 | 9 | You can create a [GitHub 10 | issue](https://github.com/kernelci/kernelci-core/issues/new?assignees=&labels=&template=new-kernel-branch.md&title=Add+branch+BRANCH+from+TREE) 11 | and fill the form to describe what you need. Typically, branches from 12 | individuals can get a small number of builds while large subsystems or mainline 13 | will get full build and test coverage to be able to use available resources in 14 | a sustainable way. 15 | 16 | **Q: What is KCIDB?** 17 | 18 | The KCIDB project, or Kernel CI Database, is a place where all kernel test 19 | results can be sent together and combined. One of the main goals is to be able 20 | to send a single email report on behalf of the multitude of test systems that 21 | produced the data. This should make maintainers' lives easier and be more 22 | effective. A [web dashboard](https://kcidb.kernelci.org) is also being worked 23 | on for similar reasons, but with access to the full details with flexible data 24 | visualisation. The KCIDB dataset may also be used to compare results from 25 | various systems and generate some added value. 26 | 27 | **Q: What are “native” builds and tests?** 28 | 29 | Kernel builds and tests scheduled by kernelci.org directly are called “native”, 30 | to help differentiate with those coming from other independent systems into 31 | KCIDB. 32 | 33 | **Q: What is the relationship between KernelCI and LAVA? Does KernelCI have 34 | non-upstream changes to LAVA? Do LAVA people participate in KernelCI?** 35 | 36 | LAVA is used in many test labs that provide results to KernelCI, but KernelCI 37 | doesn’t run any labs itself. Some people do contribute to both, as KernelCI is 38 | one of the biggest public use-cases of LAVA, but they really are independent 39 | projects. The core KernelCI tools are designed to facilitate working with LAVA 40 | labs, but this is not a requirement and other test lab frameworks are also 41 | used. 42 | 43 | **Q: Is there any documentation on how to write “custom” tests and to integrate 44 | them with KernelCI?** 45 | 46 | A section of the documentation is dedicated to [adding new test 47 | suites](/maestro/pipeline/developer-documentation/). 48 | 49 | Each test is a bit different as they all have their own dependencies and are 50 | written in various languages. Typically, they will require a user-space image 51 | with all the required packages installed to be able to run as well as the 52 | latest versions of some test suites built from source. This is the case with 53 | `v4l-utils`, `igt-gpu-tools` or `LTP`. Some are plain scripts and don’t depend 54 | on anything in particular, such as `bootrr`. 55 | 56 | When prototyping some new tests to run in LAVA, the easiest approach is to use 57 | nfsroot with the plain Debian Buster image provided by KernelCI and install 58 | extra packages at runtime, before starting the tests. Then when this is working 59 | well, dependencies and any data files can be baked into a fixed rootfs image 60 | for performance and reproducibility. 61 | -------------------------------------------------------------------------------- /kernelci.org/content/en/kci-dev: -------------------------------------------------------------------------------- 1 | ../../external/kci-dev/docs -------------------------------------------------------------------------------- /kernelci.org/content/en/kcidb: -------------------------------------------------------------------------------- 1 | ../../external/kcidb/doc/ -------------------------------------------------------------------------------- /kernelci.org/content/en/kernel-community/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Using KernelCI services" 3 | date: 2024-07-03 4 | description: "Adding trees, tests and interacting with tests results" 5 | weight: 2 6 | --- 7 | 8 | The Kernel Community is the main audience of KernelCI. Upstream maintainers and developers, product makers, hardware vendors, etc. are all interested in getting the kernel tested on a variety of scenarios. 9 | 10 | > We know that the documentation above may not answer all your questions. We are working to improve it. We ask you to reach out to our mailing list at [kernelci@lists.linux.dev](mailto:kernelci@lists.linux.dev) with questions and feedback. We are eager to hear from you! 11 | 12 | When using KernelCI, the first step is to configure trees, kernel configs and tests. Then, with the tests running, users want to evaluate results through the [dashboard](https://dashboard.kernelci.org/), [kci-dev](https://kci.dev/) and setup notifications. 13 | 14 | ## Enabling trees and tests 15 | 16 | ### Check if KernelCI already runs what you need 17 | 18 | Before we learn how to add a tree and/or tests to KernelCI, we should check if that tree is already being tested by the KernelCI ecosystem and which tests are running on it. To do that navigate through the [dashboard](https://dashboard.kernelci.org/) and look for the tree you are interested in. Multiple CI systems (origins) send test results to KernelCI, so remember to check all different origins in the Dashboard. There you can search for specific tests being run. 19 | 20 | ### Add new trees and tests 21 | 22 | If you look at the [KernelCI Architecture](../architecture/), you see **Maestro** and the systems in the **CI ecosystem** contributing results to KCIDB. This guide will explain how to add trees and tests to [Maestro](../maestro/) as it is part of the Core KernelCI infrastructure we make available for the community. If you need to add your tests to another CI system, contact them directly. 23 | 24 | This section of the documentation shares instructions to: 25 | * [enable kernel testing for your tree/branch](../maestro/pipeline/developer-documentation/#enabling-a-new-kernel-tree) 26 | * [enable specific tests](../maestro/pipeline/developer-documentation/#enabling-a-new-test) 27 | 28 | For suggestions of device tests, see [device kselftests](device-tests). 29 | 30 | ## Interacting with the results 31 | 32 | The Kernel Community has a few options to interact with the test results available in KernelCI. Remember this data includes results from several CI systems. 33 | 34 | ### Web Dashboard 35 | 36 | Our [Web Dashboard](https://dashboard.kernelci.org/): The new Dashboard aims at providing an easy way for the community to look at the test results. It is still under development and we are open to your [feedback and feature requests](https://github.com/kernelci/dashboard/issues). 37 | 38 | ### kci-dev cli 39 | 40 | We created [kci-dev](https://kci.dev/) - a command-line tool for interacting with KernelCI. You can use the [kci-dev results](https://kci.dev/results/) command to pull results from the dashboard in your shell. 41 | 42 | ### Grafana 43 | 44 | Our [Grafana](https://grafana.kernelci.org/) instance allow users to create specific dashboard with tailored queries and boards. Those who want to dive deeper into their data can engage with our Grafana instance. 45 | 46 | ## Setting up notifications 47 | 48 | Although still under development, the dashboard is already capable of sending notifications of two types: 49 | 50 | * new build regressions ([example](https://groups.io/g/kernelci-results/message/58781)) 51 | * status summary for a given revision of tree/branch([example](https://groups.io/g/kernelci-results/message/58778)) 52 | 53 | If you want to have notifications enabled for you needs, create an [new issue](https://github.com/kernelci/dashboard/issues/new) on the dashboard project detailing your usecase and we will work together with you to enable what you need. 54 | -------------------------------------------------------------------------------- /kernelci.org/content/en/kernel-community/device-tests.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Device kselftests" 3 | date: 2024-10-01 4 | description: Overview of the process of enabling device kselftests on new platforms 5 | --- 6 | 7 | Device kselftests provide a good starting point to validate basic kernel 8 | functionality. There are a few of them upstream, with varying coverage and 9 | requirements. See this documentation page for more information: 10 | https://lore.kernel.org/all/20241001-kselftest-device-docs-v1-1-be28b70dd855@collabora.com 11 | 12 | After deciding which test to run and satisfying its requirement (if any), 13 | enabling the test on a new platform in KernelCI is a matter of adding the 14 | platform to the test's scheduler entry. For example, for the DT kselftest on 15 | ARM64, that would be adding the platform here: 16 | 17 | https://github.com/kernelci/kernelci-pipeline/blob/08e7bce8044d04faa79028273384d9c30a1f5d9e/config/pipeline.yaml#L2495 18 | 19 | For the other tests, just look for the entry in the ``scheduler`` that has 20 | ``collections`` set to the kselftest path as per the upstream documentation (for 21 | example, for the error logs test, look for ``collections: devices/error_logs``). 22 | To enable the test on a different architecture, look for the entry that has the 23 | build corresponding to that architecture, or create it if there's none. See 24 | https://docs.kernelci.org/maestro/pipeline/developer-documentation/#an-example-of-enabling-a-new-job 25 | for more details on enabling tests in KernelCI. 26 | 27 | Note: In addition to the tests described in the upstream documentation, there is 28 | also an alternative to the DT kselftest for ACPI platforms: the ``acpi`` 29 | kselftest. It is not described there as it hasn't been merged upstream, but it 30 | is already being run in KernelCI. 31 | -------------------------------------------------------------------------------- /kernelci.org/content/en/labs/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Labs" 3 | date: 2024-07-03 4 | description: "Connecting labs to KernelCI" 5 | --- 6 | 7 | Anyone can connect their test labs to KernelCI. Once a lab is connected to KernelCI, it can execute KernelCI tests. 8 | 9 | It is up to each lab to define whether it will receive specific test configurations or a generic range of test jobs. If the lab is a LAVA lab, for example, the KernelCI [LAVA runtime](../maestro/pipeline/connecting-lab) will generate test jobs for each single test that is configured to run. On the other hand, if a lab is implementing its own runtime (or bridge to Maestro APIs), they may choose to generate the individual test jobs themselves. 10 | 11 | If you are interested in just sending the results of test runs in your infrastructure, you should look at sending the data to [KCIDB](../kcidb) - KernelCI common database for results. 12 | 13 | There are a few ways labs can be connected to KernelCI. The documentation for connecting labs in the new architecture is evolving as we add labs. 14 | 15 | * [Connecting a LAVA lab](../maestro/pipeline/connecting-lab) 16 | * Writing your own bridge/runtime using Maestro APIs (doc TBD, see this [GitHub issue](https://github.com/kernelci/kernelci-project/issues/349#issuecomment-2097641023)) 17 | 18 | We know that the documentation above may not answer all your questions. We are working to improve it. We ask you to reach out to our mailing list at [kernelci@lists.linux.dev](mailto:kernelci@lists.linux.dev) with questions and feedback. We are eager to hear from you! -------------------------------------------------------------------------------- /kernelci.org/content/en/maestro/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Maestro" 3 | date: 2024-05-29 4 | description: "Maestro API and Pipeline" 5 | weight: 2 6 | --- 7 | 8 | ## API Overview 9 | 10 | The Maestro API is a server-side service which provides two main features: a 11 | database abstraction and a publisher / subscriber interface. Another important 12 | concept is the fact that users own the data they send to the API. Let's have a 13 | quick look at how this all fits together. 14 | 15 | ### Database Abstraction 16 | 17 | All the data managed by Maestro is stored in a MongoDB database using node 18 | objects. These can contain data about any part of the testing hierarchy such 19 | as a kernel revision, a build, static test results, runtime functional tests, 20 | regressions etc. Each node has a parent so they form a simple tree. There is 21 | typically one root node for each kernel revision with lots of child nodes 22 | containing all the test data that relates to it. 23 | 24 | Each node object also has a state which can be used when orchestrating the 25 | pipeline. For example, a node will be in the Running state while awaiting some 26 | results. There's also a result value, to tell whether the related pipeline 27 | step that produced the node passed or failed. Finally there's a list of 28 | artifacts with URLs to know where to find all the related files (binaries, 29 | logs, generated results etc.). 30 | 31 | > **Note:** The API doesn't manage storage, the only requirement is to provide 32 | > publicly-available HTTP(S) URLs for each artifact. 33 | 34 | ### Publisher / Subscriber Interface 35 | 36 | Every time some data changes in the database, basically every time a node 37 | has been added or updated, an event is sent on the Publisher / Subscriber 38 | interface (Pub/Sub). For example, when a new kernel revision is found and a 39 | new node is created for it, an event will be sent to tell subscribers about it 40 | with something like "A checkout node has been created for kernel revision 41 | v6.2-rc4". The actual event is a [CloudEvents](https://cloudevents.io) object 42 | with some JSON data containing a subset of the corresponding node database 43 | entry. 44 | 45 | Any client code can subscribe to receive events with an API token and implement 46 | features based on how to handle these events. The API generates events 47 | automatically whenever nodes are changing but clients may also use the 48 | interface to publish their own events and coordinate other parts of the 49 | pipeline too. 50 | 51 | ### User Ownership 52 | 53 | Interacting with the API requires a token which is associated with a particular 54 | user. Whenever a user sends some data such as a new node, it is owned by that 55 | user. While all nodes are publicly readable, only the owner of the node can 56 | update it. Users can also belong to groups to share data with other users. 57 | 58 | While the main KernelCI pipeline will be creating nodes with users from a 59 | particular `kernelci.org` group, all the other users can create their own data 60 | which will coexist in the database. Then your own nodes can have parents 61 | created by users. For example, you may submit test results that relate to a 62 | kernel build provided by KernelCI. 63 | 64 | ## Pipeline 65 | 66 | The Pipeline is made up of all the client-side services that run the actual 67 | workloads that produces data and artifacts. It's orchestrated based on events 68 | from the Pub/Sub interface and all the data is managed via the API. For 69 | example, the pipeline is responsible for detecting new kernel revision, 70 | scheduling builds and tests, sending email reports and detecting regressions. 71 | However, any other service which has an API token is in fact part of the 72 | extended pipeline too. 73 | 74 | Pipeline services are also responsible for uploading various kinds of artifacts 75 | to some independent storage services and provide public URLs to access them. 76 | Artifacts typically include kernel source code tarballs, build artifacts, logs 77 | and test results in some raw format before they were submitted to the API. 78 | 79 | ## Instances 80 | 81 | ### Staging 82 | 83 | An instance has been set up on `staging.kernelci.org` for testing all pending 84 | changes. The Docker logs are available in real-time via a [web 85 | interface](https://staging.kernelci.org:9088/) for both the API and the 86 | pipeline. It also provides some [interactive API 87 | documentation](https://staging.kernelci.org:9000/latest/docs). This instance 88 | is not stable, it's redeployed periodically with all open pull requests from 89 | GitHub merged together on a test integration branch. 90 | Please check [docs](/maestro/api/staging) for more details. 91 | 92 | ### Production 93 | 94 | Production instance has been deployed in the Cloud (AKS) 95 | on `kernelci-api.westus3.cloudapp.azure.com`. This is stable instance and is being updated weekly (usually on Mondays). Like 96 | staging, it has an auto-generated [interactive API 97 | documentation](https://kernelci-api.westus3.cloudapp.azure.com/latest/docs). 98 | -------------------------------------------------------------------------------- /kernelci.org/content/en/maestro/api: -------------------------------------------------------------------------------- 1 | ../../../external/kernelci-api/doc -------------------------------------------------------------------------------- /kernelci.org/content/en/maestro/contrib.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Contributing Guidelines" 3 | date: 2024-09-12T16:33:00Z 4 | draft: false 5 | weight: 2 6 | --- 7 | 8 | KernelCI core project is open for contributions. Contributions may consist of 9 | adding new builds, tests and device types as well as features and bugfixes for 10 | KernelCI core tools. 11 | When the PR is created, the [KernelCI staging](https://kernelci.org/docs/instances/staging) 12 | instance takes care of updating the [staging.kernelci.org branch](https://github.com/kernelci/kernelci-core/tree/staging.kernelci.org). 13 | In general the branch is updated every 8h and a limited set of builds and tests 14 | are run on it. 15 | 16 | There are several guidelines which can facilitate the PR review process: 17 | 18 | 1. Make sure the PR is well described 19 | 1. Describe the purpose of the changes 20 | 2. Example use cases are welcome 21 | 2. Attach staging build/test results when possible. 22 | 1. If the PR is expected to produce build/test results 23 | check [staging viewer](https://staging.kernelci.org:9000/viewer) and make sure these are mentioned in the PR comment 24 | 1. Build artifacts including logs are not kept permanently, so it's generally recommended to put them in a place that'd make them last if you want them to be part of the PR. Good way to do that seem to be: 25 | * Putting important information such as log fragments in the PR comments 26 | * Using services like [pastebin](https://pastebin.com/) to store data important for the PR (e.g. full logs) and pasting the links. 27 | 2. If the results are not visible on staging and you think they should be, mention it in the comments, too 28 | 3. If there is specific way to verify PR is working as expected, mention it in the comments 29 | 3. Make sure that reviewers' comments and questions are addressed 30 | 1. When there are comments unanswered for more than 1 month the PR will be closed 31 | 4. In case there is a need to consult the PR with KernelCI maintainers join the [open hours](https://docs.kernelci.org/org/#open-hours) 32 | 5. Should you need help, you can reach KernelCI [maintainers](/org/maintainers/) or the community on the [KernelCI website](https://kernelci.org/community-contact/) 33 | -------------------------------------------------------------------------------- /kernelci.org/content/en/maestro/pipeline: -------------------------------------------------------------------------------- 1 | ../../../external/kernelci-pipeline/doc -------------------------------------------------------------------------------- /kernelci.org/content/en/org/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Organization" 3 | date: 2021-09-03 4 | description: "KernelCI project organization" 5 | weight: 1 6 | aliases: 7 | - "/team/" 8 | --- 9 | 10 | The KernelCI Linux Foundation project is composed of an [Advisory Board](board) 11 | with representatives from all the [member organizations](members) as well as a 12 | [Technical Steering Committee](tsc). A number of [working 13 | groups](working-groups) are also focusing on particular areas of the project. 14 | 15 | ## Mission Statement 16 | To ensure the quality, stability and long-term maintenance of the Linux kernel 17 | by maintaining an open ecosystem around test automation practices and 18 | principles. 19 | 20 | ### Objective: Maintainer buy-in 21 | Drive for adoption of the project as an integral part of the Linux kernel 22 | development workflow by Linux kernel maintainers. 23 | 24 | **Key Results** 25 | * Maintainers require basic CI to pass before reviewing/accepting/merging 26 | * Maintainers require test cases for acceptance of new features running in CI 27 | 28 | ### Objective: Broad adoption 29 | Promote participation from and adoption by kernel developers, and hardware 30 | manufacturers to use and improve the ecosystem. 31 | 32 | **Key Results** 33 | * Kernel developer community becomes dependent on good automation and CI 34 | * Hardware manufacturers depend on KernelCI for production kernel quality 35 | * Downstream kernels depend on upstream testing by KernelCI 36 | 37 | ### Objective: Community collaboration 38 | Join forces with existing testing projects and work towards a shared set of 39 | tooling and infrastructure. 40 | 41 | **Key Results** 42 | * Consolidated email reports going to kernel community: “one report to rule them 43 | all” 44 | * Maintain a shared reporting and visualization service (kernelci.org) for 45 | upstream kernel testing 46 | * Maintain a shared set of code and tools available for use by derivative 47 | projects 48 | 49 | ### Objective: Membership growth 50 | In order to achieve the mission and objectives, funding is needed. Funding comes 51 | primarily from project membership dues through the Linux Foundation. 52 | 53 | **Key Results** 54 | * Highlight member technologies 55 | * New members: 1-2 per year 56 | * Available funding for on-going project management, software development, 57 | infrastructure, support and community engagement initiatives 58 | 59 | ## Project Documentation 60 | These are the main documents defining how the project works: 61 | 62 | ### Funding Charter 63 | 64 | > Thank you for your interest in joining the KernelCI Initiative (the “Directed 65 | Fund”), a directed fund project of The Linux Foundation (the “LF”). The purpose 66 | of the Directed Fund is to raise, budget and spend funds in support of the 67 | KernelCI Project a Series of LF Projects, LLC (the “Technical Project”), an 68 | open source project and individual series of LF Projects, LLC, a Delaware 69 | series limited liability company. The governance for the Directed Fund will 70 | operate pursuant to the Directed Fund Charter (the “Charter”), set forth as 71 | Exhibit B, and as amended in the future by the Governing Board with the 72 | approval of the LF. **Please note** that you must be a member of the LF to be 73 | eligible to participate as a member of the Directed Fund. For further 74 | information, visit the [Corporate 75 | Membership](https://www.linuxfoundation.org/join/members/) page at the LF web 76 | site. 77 | 78 | [KernelCI_Participation_Agreement_and_Funding_Charter_20180913.pdf 79 | ](/files/KernelCI_Participation_Agreement_and_Funding_Charter_20180913.pdf) 80 | 81 | ### Technical Charter 82 | 83 | > This charter (the “Charter”) sets forth the responsibilities and procedures 84 | for technical contribution to, and oversight of, the KernelCI Project, which 85 | has been established as KernelCI Project a Series of LF Projects, LLC (the 86 | “Project”). LF Projects, LLC (“LF Projects”) is a Delaware series limited 87 | liability company. All Contributors to the Project must comply with the terms 88 | of this Charter. 89 | 90 | [KernelCI_Project_Technical_Charter_20181107.pdf 91 | ](/files/KernelCI_Project_Technical_Charter_20181107.pdf) 92 | 93 | ## Meetings 94 | 95 | Several periodic meetings are scheduled for different purposes: 96 | 97 | ### Community Weekly 98 | 99 | * Every Thursday at 11:00 UTC on [Jitsi](https://meet.jit.si/kernelci-dev) 100 | 101 | This is a public meeting for general discussions with anyone interested in the 102 | project. A shared document is used to keep the minutes and an agenda is 103 | prepared ahead of the meeting. 104 | 105 | ### Open Hours 106 | 107 | * EMEA/APAC: Every Thursday at 12:00 UTC on 108 | [Jitsi](https://meet.jit.si/kernelci-dev) 109 | 110 | * EMEA/AMER: Every Wednesday at 18:00 UTC on 111 | [Jitsi](https://meet.jit.si/kernelci-dev) 112 | 113 | The Open Hours are additional public meetings for informal technical 114 | discussions: new users who are getting started, kernel maintainers who want to 115 | have their tests run in KernelCI, kernel bugs reported by KernelCI, pending 116 | KernelCI code changes on GitHub etc. They help offload the community weekly to 117 | keep it more high-level and ensure all the people involved in the project can 118 | discuss the most important topics then. 119 | 120 | The Wednesday Open Hours session is more convenient for people in the AMER 121 | timezones than the Thursday meetings, and things discussed on Wednesday should 122 | be shared during the Thursday meeting. 123 | 124 | ### Advisory Board 125 | 126 | * Every other Wednesday at 07:30 PST 127 | 128 | The [Advisory Board](/org/board/) of members meet every other week to 129 | discuss things that matter from the point of view of the KernelCI Linux 130 | Foundation project: budget, membership, work packages, internships etc. It's a 131 | private meeting as only member representatives can attend. 132 | 133 | ### Technical Steering Committee 134 | 135 | * Every second Thursday of the month at 10:00 UTC 136 | 137 | The [Technical Steering Committee](/org/tsc/) meet once a month to discuss 138 | general technical topics that have a significant impact on the project. This 139 | is a private meeting as only elected TSC members can attend and they 140 | occasionally take part in decisions made by the advisory board. 141 | -------------------------------------------------------------------------------- /kernelci.org/content/en/org/board.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Advisory Board" 3 | date: 2024-04-01 4 | description: "Linux Foundation Project Board" 5 | weight: 2 6 | aliases: 7 | - "/team/board" 8 | --- 9 | 10 | The Advisory Board (AB) is composed of one representative from each premium 11 | member organization, one representative for every five general member 12 | organizations (maximum of three) and the TSC Chair. 13 | 14 | By the end of December each year, the Board agrees on a budget for the next 15 | year and submits it to the Linux Foundation. It then elects a Chair, a 16 | Treasurer and a General Members representative for the following year. The new 17 | roles and budget take effect on January 1st. 18 | 19 | In addition to the elected roles, there is also an appointed Project Manager to 20 | help coordinate activities with the TSC, working groups and the wider team. 21 | 22 | As of 2024, the Advisory Board is composed of the members listed below with 23 | their respective roles, email address and IRC nicknames: 24 | 25 | * [Chris Paterson](mailto:) (Civil Infrastructure Platform project, Treasurer) - `patersonc` 26 | * [Don Zickus](mailto:) (Red Hat, Chair) 27 | * [Greg Kroah-Hartman](mailto:) (Linux Foundation) - `gregkh` 28 | * [Guenter Roeck](mailto:) (Google) 29 | * [Gustavo Padovan](mailto:) (Collabora, Project Manager) - `padovan` 30 | * [Guy Lunardi](mailto:) (Collabora, Marketing) - `glunardi` 31 | * [Kevin Hilman](mailto:) (BayLibre, General Members Representative) - `khilman` 32 | * [KY Srinivasan](mailto:) (Microsoft) 33 | * [Nikolai Kondrashov](mailto:) (TSC Chair) - `spbnick` 34 | 35 | Learn more about the [current members](/org/members) or how to join on the 36 | [KernelCI Linux Foundation](https://kernelci.org/) website. 37 | 38 | ## Key Roles 39 | 40 | As a matter of transparency and to ensure long-term continuity of operation, 41 | some key roles for the Board are defined below. These are based on the Funding 42 | Charter as well as various contracts and other agreements to reflect the status 43 | quo. 44 | 45 | ### Chair 46 | 47 | As per the Funding Charter provided by the Linux Foundation: 48 | 49 | > The Chair will preside over meetings of the Governing Board, manage any 50 | > day-to-day operational decisions, and will submit minutes for Governing Board 51 | > approval. 52 | 53 | Then in the particular case of KernelCI, past discussions have led the Board to 54 | agree on the following responsibilities: 55 | 56 | * Plan and execute on the project's initiatives autonomously 57 | * Drive the AB and TSC to help reach the strategic priorities of the project 58 | * Encourage strong engagement and community participation 59 | * Explore relationships with industry alliances to increase the project's reach 60 | * Participate in the community to help foster adoption and collaboration 61 | * Develop partnerships and other strategic relationships with key projects and 62 | companies 63 | * Promote the project for potential new members to join 64 | * Devise and deliver visibility for the project at key conferences and events 65 | * Attend conferences and organize speaking engagements at relevant events 66 | 67 | ### Treasurer 68 | 69 | As per the Funding Charter provided by the Linux Foundation: 70 | 71 | > The Treasurer will assist in the preparation of budgets for Governing Board 72 | > approval, monitor expenses against the budget and authorize expenditures 73 | > approved in the budget. 74 | 75 | The specifics for KernelCI are not further detailed but typically include 76 | liaising with the Linux Foundation for any finance-related business such as 77 | setting up contracts and dealing with invoices. 78 | 79 | ### Project Manager 80 | 81 | While many projects have a PM, this particular role has been entirely defined 82 | by KernelCI board members with the following responsibilities: 83 | 84 | * Manage the day-to-day activities for the project (both AB and TSC efforts) 85 | * Organize and run the AB regular calls and meetings 86 | * Mediate potential conflicts that may arise in the AB and TSC 87 | * Report the progress of the project to the LF Technical Advisory Board (TAB) 88 | * Ensure the maintenance of the project infrastructure is happening (build 89 | farms, test labs, test nodes, key databases etc.) 90 | * Prioritize work that drives toward completion of the project objectives and 91 | key results (OKRs) 92 | * Coordinate note taking and the capture of action items 93 | * Communicate progress and status via reports 94 | * Ensure action items are managed and delivered 95 | 96 | ### Representatives 97 | 98 | Other voting members of the Board include: 99 | 100 | * Premium Member representatives 101 | * General Member representatives 102 | * TSC representative 103 | 104 | They are all expected to cast a vote and take part in the Board meetings to 105 | take initiatives and help the project thrive. 106 | -------------------------------------------------------------------------------- /kernelci.org/content/en/org/branding/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Branding" 3 | date: 2024-06-10 4 | description: "Logo and Branding guidelines" 5 | weight: 8 6 | --- 7 | 8 | ![branding](kernelci_brand.svg) 9 | 10 | Our branding guidelines are available for download as: [SVG](kernelci_brand.svg) | [PDF](kernelci_brand.pdf) 11 | 12 | ## Logo files 13 | 14 | KernelCI logo (color) [SVG](kernelci-logo-color.svg) | [PNG](kernelci-logo-color.png) 15 | 16 | KernelCI logo (black) [SVG](kernelci-logo-black.svg) 17 | 18 | KernelCI logo (white) [SVG](kernelci-logo-white.svg) 19 | 20 | ### Legal notice 21 | 22 | By using the KernelCI trademark and logo, you agree to follow these guidelines as well as the trademark usage statement of The Linux Foundation. These guidelines apply to your use of the KernelCI trademark and logo. 23 | 24 | The KernelCI Advisory Board reserves the right to grant or deny any permission at its sole discretion and for any reason. If you have any questions about these guidelines, please contact [kernelci-members@groups.io](mailto:kernelci-members@groups.io). 25 | 26 | KernelCI is a registered trademark of The Linux Foundation. For more information and statement, please visit https://linuxfoundation.org/trademark-usage/ -------------------------------------------------------------------------------- /kernelci.org/content/en/org/branding/kernelci-logo-black.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 16 | 17 | 18 | 19 | 20 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 33 | 34 | 35 | 36 | 37 | 39 | 40 | 41 | 42 | 43 | 45 | 46 | 47 | 48 | 49 | 51 | 52 | 53 | 54 | 55 | 57 | 58 | 59 | 60 | 61 | 62 | 65 | 67 | 69 | 72 | 74 | 75 | 76 | 79 | 80 | 81 | 82 | 83 | -------------------------------------------------------------------------------- /kernelci.org/content/en/org/branding/kernelci-logo-color.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/kernelci.org/content/en/org/branding/kernelci-logo-color.png -------------------------------------------------------------------------------- /kernelci.org/content/en/org/branding/kernelci-logo-color.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | image/svg+xml 44 | 50 | 52 | 54 | 56 | 60 | 61 | 62 | 64 | 66 | 68 | 72 | 73 | 74 | 76 | 78 | 82 | 83 | 84 | 86 | 88 | 92 | 93 | 94 | 96 | 98 | 102 | 103 | 104 | 106 | 108 | 112 | 113 | 114 | 116 | 120 | 124 | 128 | 132 | 136 | 140 | 141 | 142 | 143 | 145 | 147 | 149 | 153 | 154 | 155 | 157 | 159 | 163 | 164 | 165 | 167 | 169 | 173 | 174 | 175 | 177 | 181 | 185 | 186 | 187 | 188 | -------------------------------------------------------------------------------- /kernelci.org/content/en/org/branding/kernelci-logo-white.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 5 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 19 | 20 | 21 | 22 | 23 | 25 | 26 | 27 | 28 | 29 | 31 | 32 | 33 | 34 | 35 | 37 | 38 | 39 | 40 | 41 | 43 | 44 | 45 | 46 | 47 | 49 | 50 | 51 | 52 | 53 | 55 | 56 | 57 | 58 | 59 | 61 | 62 | 63 | 64 | 65 | 66 | 69 | 71 | 73 | 76 | 78 | 79 | 80 | 83 | 84 | 85 | 86 | 87 | -------------------------------------------------------------------------------- /kernelci.org/content/en/org/branding/kernelci_brand.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/kernelci.org/content/en/org/branding/kernelci_brand.pdf -------------------------------------------------------------------------------- /kernelci.org/content/en/org/lfx.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "LFX Insights" 3 | date: 2024-09-04 4 | description: "Details of our LFX insights account" 5 | --- 6 | 7 | KernelCI has an [overview board](https://insights.lfx.linuxfoundation.org/foundation/kernelci/overview/github?project=kernelci-project&routedFrom=Github) in the [LFX Insights](https://insights.lfx.linuxfoundation.org/) platform. 8 | 9 | Here is a list of repos enabled in the platform: 10 | 11 | * [kernelci-project](https://github.com/kernelci/kernelci-project) 12 | * [kcidb](https://github.com/kernelci/kcidb) 13 | * [kernelci-core](https://github.com/kernelci/kernelci-core) 14 | * [kernelci-pipeline](https://github.com/kernelci/kernelci-pipeline) 15 | * [kernelci-api](https://github.com/kernelci/kernelci-api) 16 | * [kernelci-deploy](https://github.com/kernelci/kernelci-deploy) 17 | * [platform-test-parameters](https://github.com/kernelci/platform-test-parameters) 18 | * [kcidb-io](https://github.com/kernelci/kcidb-io) 19 | * [kcidb-grafana](https://github.com/kernelci/kcidb-grafana) 20 | * [dashboard](https://github.com/kernelci/dashboard) 21 | * [kci-dev](https://github.com/kernelci/kci-dev) 22 | * [logspec](https://github.com/kernelci/logspec) 23 | 24 | If you need to add/change the repos, contact the LF team through the Support part of the platform. -------------------------------------------------------------------------------- /kernelci.org/content/en/org/members.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Members" 3 | date: 2024-12-03 4 | description: "Member companies who fund the KernelCI project" 5 | weight: 1 6 | --- 7 | 8 | The success of the KernelCI project is driven by contributions from our 9 | developer community and organizations joining as members. 10 | 11 | Learn how your organization can contribute to the project now by [sending us an 12 | email](mailto:kernelci-members@groups.io?subject=KernelCI%20membership%20information%20request), 13 | or join the project directly through the [Linux Foundation LFX website](http://joinnow.platform.linuxfoundation.org/?project=kernelci). 14 | 15 | Below are the current members of the project. 16 | 17 | ## Premium Members 18 |
19 |
20 |
Civil Infrastructure Platform
21 |
Collabora
22 |
Google
23 |
Linaro
24 |
Microsoft
25 |
Red Hat
26 |
Texas Instruments
27 |
28 |
29 | 30 | ## General Members 31 |
32 |
33 |
Baylibre
34 |
35 |
36 | 37 | ## Associate Members 38 |
39 |
40 |
ELISA
41 |
42 |
43 | -------------------------------------------------------------------------------- /kernelci.org/content/en/org/tsc/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Technical Steering Committee" 3 | date: 2024-03-18 4 | description: "KernelCI core developers and maintainers" 5 | weight: 3 6 | aliases: 7 | - "/team/tsc" 8 | --- 9 | 10 | The Technical Steering Committee (TSC) is a team of people who are responsible 11 | for keeping the KernelCI project in a good shape and driving its development. 12 | The [rules](#rules) are based on the LF [project 13 | charter](/files/KernelCI_Project_Technical_Charter_20181107.pdf). Typically, 14 | major contributors eventually become members and those who have stopped 15 | contributing for an extended period of time may be removed. 16 | 17 | ## Members 18 | 19 | As of today, the committee is composed of the members listed below with their 20 | respective email address and IRC nicknames: 21 | 22 | * [Kevin Hilman](mailto:) - `khilman` 23 | * [Mark Brown](mailto:) - `broonie` 24 | * [Guillaume Tucker](mailto:) - `gtucker` 25 | * [Nikolai Kondrashov](mailto:) - `spbnick` 26 | * [Michał Gałka](mailto:) - `mgalka` 27 | * [Arisu Tachibana](mailto:) - `arisut` 28 | * [Denys Fedoryshchenko](mailto:) - `nuclearcat` 29 | * [Jeny Sadadia](mailto:jeny.sadadia@collabora.com) - `jenysadadia` 30 | * [Paweł Wieczorek](mailto:pawiecz@collabora.com) - `pawiecz` 31 | * [Shuah Khan](mailto:skhan@linuxfoundation.org) - `shuah` 32 | 33 | ## Communication 34 | 35 | For general discussions, the usual IRC channel `#kernelci` on libera.chat and 36 | the [`kernelci@lists.linux.dev`](mailto:) mailing 37 | list can be used. To contact only the TSC members directly, the 38 | [`kernelci-tsc@groups.io`](mailto:) private list may be 39 | used instead. 40 | 41 | The TSC also meet monthly online to discuss current topics and make decisions 42 | including votes when necessary. See the [Meetings 43 | section](/org/#technical-steering-committee) for more details. 44 | 45 | ## Rules 46 | 47 | ### Votes 48 | 49 | As per paragraph *3.a TSC Voting* of the [project 50 | charter](/files/KernelCI_Project_Technical_Charter_20181107.pdf): 51 | 52 | > While the Project aims to operate as a consensus based community, if any TSC 53 | > decision requires a vote to move the Project forward, the voting members of 54 | > the TSC will vote on a one vote per voting member basis. 55 | 56 | Decisions that always require a vote are: 57 | * adding or removing TSC members 58 | * making changes to the TSC rules 59 | * granting or removing any kind of admin rights to individuals 60 | * making proposals to the LF project board 61 | 62 | Votes are made on motions with a yes/no choice and have to be proposed by a TSC 63 | member. The result of each vote should be shared on the mailing list and added 64 | to the [voting records](votes). It should also include the date when any 65 | related changes are enacted. As such they provide a way to keep a formal trace 66 | of decisions being made. 67 | 68 | **Votes done during a live meeting** require a quorum of 50% of the TSC members 69 | to be present in the meeting and a majority of "yes" votes among these voting 70 | members to move the motion. However, to make sure that everyone has a say, 71 | voting in a meeting should preferably be done only when at least 90% of the 72 | members are in attendance. 73 | 74 | **Votes done by email** or any other deferred channel require a majority among 75 | all of the TSC members as everyone is expected to be able to take part. Votes 76 | by email expire after a period of two weeks: the motion will be rejected if a 77 | majority of "yes" votes from the whole TSC hasn't been reached by then. 78 | 79 | Because our members are spread across the world, and normally cannot attend a 80 | meeting all at once, the preferred approach is to vote by email. 81 | 82 | Abstentions are not counted as votes. Effectively, they are the same as not 83 | attending a meeting or not replying to an email. For example, with 7 TSC 84 | members in a meeting, if 3 are abstaining, 3 vote "yes" and 1 votes "no", we 85 | have quorum as 4/7 are voting and a majority as 3/4 voted "yes" - and the 86 | motion is moved. 87 | 88 | ### Members 89 | 90 | Current members of the TSC may propose to vote for new people to be added or 91 | removed. This should prevent a single organisation from taking over the TSC. 92 | People to be considered as new TSC members should have typically played an 93 | important role for a significant amount of time in the project. There is 94 | however no strict requirement, the only condition is the outcome of the TSC 95 | vote. 96 | 97 | Likewise, members of the TSC may propose that a member be removed which should 98 | result in a motion and a vote. Members who have not been active for over a 99 | year should be notified and considered for removal from TSC in order to keep 100 | the list up-to-date with the reality of the project. 101 | 102 | The criteria for removing a member aren't strictly defined either, in the end 103 | it's up to the TSC to vote and judge whether a member should be removed due to 104 | inactivity. Members who commit acts that pose a threat to the stability of the 105 | project may also be removed following a TSC vote. 106 | 107 | ### Duties 108 | 109 | Each TSC member is responsible for taking part in making important technical 110 | decisions. As members are ideally also maintainers or active developers, it 111 | makes sense to have a committee to discuss the general roadmap or design 112 | principles to ensure cohesion within the project. It should become a natural 113 | progression when new members join the TSC to facilitate coordination with 114 | others who have been involved for a long time. 115 | 116 | In practice, active members are typically expected to: 117 | 118 | * attend TSC meetings (monthly) 119 | * participate in votes 120 | * make sustained contributions to the project, such as: 121 | * contributing to the code 122 | * doing code reviews 123 | * sharing experience and contributing ideas for solving technical issues 124 | * helping keep the services working 125 | * writing documentation or creating any content that promotes the project 126 | -------------------------------------------------------------------------------- /kernelci.org/content/en/org/working-groups.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Working groups" 3 | date: 2024-12-03 4 | description: "KernelCI Working Groups" 5 | weight: 4 6 | --- 7 | 8 | Working groups are small teams of people focusing on a particular aspect of the 9 | project. Each group typically relies on a monthly meeting and a GitHub 10 | workboard to keep track of things. 11 | 12 | There should also be a lead to coordinate activities within each group, such 13 | as: 14 | 15 | * updating the workboard 16 | * preparing regular meeting agendas and keeping minutes 17 | * sharing regular reports with the TSC, board and public mailing list 18 | 19 | ## Web dashboard 20 | 21 | **Workboard:** https://github.com/orgs/kernelci/projects/4 22 | 23 | **Mailing list:** [kernelci-webdashboard@groups.io](mailto:) 24 | 25 | **Team:** 26 | 27 | * [Gustavo Padovan](mailto:) - `padovan` - Lead 28 | * [Greg Kroah-Hartman](mailto:) - `gregkh` 29 | * [Ricardo Cañuelo](mailto:) - `hardboprobot` 30 | * [Nikolai Kondrashov](mailto:) - `spbnick` 31 | 32 | As KernelCI keeps growing, and based on the results of the [2020 Community 33 | Survey](http://localhost:1313/blog/posts/2020/07/09/), a new web dashboard is 34 | necessary in order to achieve the goals set by the project. Several attempts 35 | have been made in the past to replace the current one on 36 | [linux.kernelci.org](https://linux.kernelci.org) but none of them actually 37 | provided a viable alternative. We've since started gathering ideas from a 38 | range of users in order to produce user stories and get a clear understanding 39 | of what is required. Based on this, we'll then be looking for technical 40 | solutions including existing frameworks, dashboards used by other projects and 41 | potentially a new design from scratch using modern web technology. 42 | 43 | ## SysAdmin 44 | 45 | **Workboard:** https://github.com/orgs/kernelci/projects/7 46 | 47 | **Team:** 48 | 49 | * [Denys Fedoryshchenko](mailto:) - `nuclearcat` - Lead 50 | * [Michał Gałka](mailto:) - `mgalka` 51 | * [Corentin Labbe](mailto:) - `montjoie` 52 | * [Kevin Hilman](mailto:) - `khilman` 53 | * [Mark Brown](mailto:) - `broonie` 54 | * [Nikolai Kondrashov](mailto:) - `spbnick` 55 | * [Vince Hillier](mailto:) - `vince` 56 | * [Paweł Wieczorek](mailto:) - `pawiecz` 57 | 58 | The KernelCI common infrastructure requires some regular maintenance to keep 59 | web servers, databases and Cloud services up and running. This does not 60 | include any test lab other than some Kubernetes clusters as hardware platforms 61 | are maintained by separate companies and individuals. Members of the SysAdmin 62 | working group have admin rights on all KernelCI systems, wherever applicable. 63 | As per the [2022-12-08 TSC vote](/org/tsc/votes/#2022-12-08), admin rights 64 | cover the following items: 65 | 66 | * Machines (SSH, sudo): 67 | * Azure VMs 68 | * Kubernetes nodes 69 | 70 | * Web applications: 71 | * SysAdmin GitHub project board 72 | * Azure portal (admin access) 73 | * Encrypted repositories: 74 | * kernelci-jenkins-data 75 | * builder-config-data 76 | -------------------------------------------------------------------------------- /kernelci.org/content/en/tests/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Tests" 3 | date: 2021-08-04 4 | description: KernelCI Tests 5 | --- 6 | 7 | The fastest and preferred way to add a test and get it run by CI systems is to 8 | contribute to existing test suites: 9 | 10 | ## kselftest 11 | 12 | * The kernel source tree contains a set of “self tests” under the 13 | `tools/testing/selftests/` directory 14 | * See [Contributing to 15 | kselftests](https://www.kernel.org/doc/html/latest/dev-tools/kselftest.html#contributing-new-tests) 16 | for instructions to add tests 17 | * You can find more details at the [kselftests 18 | wiki](https://kselftest.wiki.kernel.org) 19 | * Contact: Send questions to the mailing list 20 | [linux-kselftest@vger.kernel.org](mailto:linux-kselftest@vger.kernel.org) or 21 | join the `#linux-kselftest` IRC Channel on freenode 22 | 23 | ## LTP 24 | 25 | * LTP Test source lives at the [Linux Test Project](https://linux-test-project.github.io/) 26 | * Contact: Send questions to the mailing list **ltp@lists.linux.it**. For full [contact information](https://github.com/linux-test-project/ltp/wiki/Contact-Info), including IRC, see the [LTP wiki](https://github.com/linux-test-project/ltp/wiki/Developers) 27 | * Proposing patches: You can submit Pull Requests to the [LTP project on GitHub](https://github.com/linux-test-project/ltp). 28 | * Documentation: The [LTP wiki](https://github.com/linux-test-project/ltp/wiki/Developers) has plenty of documentation to get you started. You have a [step-by-step tutorial](https://github.com/linux-test-project/ltp/blob/master/doc/c-test-tutorial-simple.txt) to create a new C test, [Guidelines](https://github.com/linux-test-project/ltp/blob/master/doc/test-writing-guidelines.txt), and other documentation. 29 | -------------------------------------------------------------------------------- /kernelci.org/data/.placeholder: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/kernelci.org/data/.placeholder -------------------------------------------------------------------------------- /kernelci.org/docker-compose.yaml: -------------------------------------------------------------------------------- 1 | # SPDX-License-Identifier: LGPL-2.1-or-later 2 | # 3 | # Copyright (C) 2022-2024 Collabora Limited 4 | # Author: Guillaume Tucker 5 | # Author: Denys Fedoryshchenko 6 | # 7 | # Description: builds and runs the hugo server with kernelci.org website 8 | # in a docker container, viewable at http://localhost:1313 9 | # 10 | # Note: 11 | # 1)retrieve all submodules with `git submodule update --init --recursive` 12 | # 2)retrieve all lfs files with `git lfs pull` 13 | # you might need to install git-lfs with `sudo apt install git-lfs` 14 | # 3)run `docker-compose up` to start the server 15 | 16 | version: '3' 17 | services: 18 | localhugo: 19 | container_name: 'localhugo' 20 | image: 'hubci/hugo:0.97.3' 21 | volumes: 22 | - '.:/src' 23 | ports: 24 | - '1313:1313' 25 | # chdir to the source directory 26 | working_dir: '/src' 27 | user: '0:0' 28 | command: 29 | - 'hugo' 30 | - 'server' 31 | - '-D' 32 | - '-F' 33 | - '--bind=0.0.0.0' 34 | -------------------------------------------------------------------------------- /kernelci.org/layouts/partials/navbar.html: -------------------------------------------------------------------------------- 1 | {{ $cover := .HasShortcode "blocks/cover" }} 2 | 34 | -------------------------------------------------------------------------------- /kernelci.org/static/favicons/android-144x144.png: -------------------------------------------------------------------------------- 1 | version https://git-lfs.github.com/spec/v1 2 | oid sha256:f2724f766ff364a55a0c0b3c2b1c66f43265650d54e8659ee064c14c023f49a8 3 | size 13990 4 | -------------------------------------------------------------------------------- /kernelci.org/static/favicons/android-192x192.png: -------------------------------------------------------------------------------- 1 | version https://git-lfs.github.com/spec/v1 2 | oid sha256:fade7cef00c2015b661107bcd2cb2f8b120fa12d8185e8ef18dedd0a1ad7e3a4 3 | size 17482 4 | -------------------------------------------------------------------------------- /kernelci.org/static/favicons/android-36x36.png: -------------------------------------------------------------------------------- 1 | version https://git-lfs.github.com/spec/v1 2 | oid sha256:08c8dc128995f9a216f32098eae50030c421bc8d37f9fad49925f9dc44cab386 3 | size 6240 4 | -------------------------------------------------------------------------------- /kernelci.org/static/favicons/android-48x48.png: -------------------------------------------------------------------------------- 1 | version https://git-lfs.github.com/spec/v1 2 | oid sha256:73b4b43cc834820ee1e9fe27a29905489dc9ef43849cf55670057fa1ab8c87fd 3 | size 7144 4 | -------------------------------------------------------------------------------- /kernelci.org/static/favicons/android-72x72.png: -------------------------------------------------------------------------------- 1 | version https://git-lfs.github.com/spec/v1 2 | oid sha256:3ef1da7b9ca48c3bfaf7e252f83ded42942189524f1c6a7883489e1c9286523e 3 | size 8859 4 | -------------------------------------------------------------------------------- /kernelci.org/static/favicons/android-96x96.png: -------------------------------------------------------------------------------- 1 | version https://git-lfs.github.com/spec/v1 2 | oid sha256:e181d1d74be2701f6a5b297ae8c6261de8113599488358c6d13febdd4972e28c 3 | size 10529 4 | -------------------------------------------------------------------------------- /kernelci.org/static/favicons/favicon-1024.png: -------------------------------------------------------------------------------- 1 | version https://git-lfs.github.com/spec/v1 2 | oid sha256:2d14c9346d8f434daa25ab1cde54c146d8e5e1aeec44cb1ba45b3ca5c949cc6b 3 | size 86525 4 | -------------------------------------------------------------------------------- /kernelci.org/static/favicons/favicon-16x16.png: -------------------------------------------------------------------------------- 1 | version https://git-lfs.github.com/spec/v1 2 | oid sha256:ba7db081f5847a341a4940ac2c9d763e8a5e151a7ed956dea61a4424de746809 3 | size 4899 4 | -------------------------------------------------------------------------------- /kernelci.org/static/favicons/favicon-256.png: -------------------------------------------------------------------------------- 1 | version https://git-lfs.github.com/spec/v1 2 | oid sha256:b9e41f47feb6208788186112e737379ee5520f01078dae458663371c79fb4392 3 | size 22343 4 | -------------------------------------------------------------------------------- /kernelci.org/static/favicons/favicon-32x32.png: -------------------------------------------------------------------------------- 1 | version https://git-lfs.github.com/spec/v1 2 | oid sha256:9c048f8b433f87b7c436452b9529260a7e7afca65f54ac89c96d9c0da995e2dc 3 | size 5899 4 | -------------------------------------------------------------------------------- /kernelci.org/static/favicons/favicon.ico: -------------------------------------------------------------------------------- 1 | version https://git-lfs.github.com/spec/v1 2 | oid sha256:b9e41f47feb6208788186112e737379ee5520f01078dae458663371c79fb4392 3 | size 22343 4 | -------------------------------------------------------------------------------- /kernelci.org/static/files/KernelCI_Participation_Agreement_and_Funding_Charter_20180913.pdf: -------------------------------------------------------------------------------- 1 | version https://git-lfs.github.com/spec/v1 2 | oid sha256:0cc06990bee27c032f5cec0d402d613b7d97221da8e4a8dfcb563568b85f2742 3 | size 165917 4 | -------------------------------------------------------------------------------- /kernelci.org/static/files/KernelCI_Project_Technical_Charter_20181107.pdf: -------------------------------------------------------------------------------- 1 | version https://git-lfs.github.com/spec/v1 2 | oid sha256:674107c4eb2935cc3e9b876576b24608c288960d0b1833f6f35c27f33eb5f1b7 3 | size 366093 4 | -------------------------------------------------------------------------------- /kernelci.org/static/image/collabora-stacked-color.svg: -------------------------------------------------------------------------------- 1 | 2 | -------------------------------------------------------------------------------- /kernelci.org/static/image/google-color.svg: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /kernelci.org/static/image/kernelci-horizontal-color.png: -------------------------------------------------------------------------------- 1 | version https://git-lfs.github.com/spec/v1 2 | oid sha256:1e0468948f4a7605da475be4061888ab396a75d9dc963c87bdcf6acabff86729 3 | size 42534 4 | -------------------------------------------------------------------------------- /kernelci.org/static/image/linaro-color.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 93 | -------------------------------------------------------------------------------- /kernelci.org/static/image/microsoft-color.svg: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /kernelci.org/static/image/redhat-color.svg: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /secrets/dump.py: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env python3 2 | 3 | """Load the TOML configuration as a basic syntax validation.""" 4 | 5 | import sys 6 | import toml 7 | 8 | 9 | def main(args): 10 | with open('passwords.toml') as f: 11 | data = toml.load(f) 12 | for section, params in data.items(): 13 | print(section) 14 | for field in ['user', 'password', 'url']: 15 | value = params.get(field) 16 | if value: 17 | print("* {}: {}".format(field, value)) 18 | 19 | 20 | if __name__ == '__main__': 21 | main(sys.argv) 22 | -------------------------------------------------------------------------------- /secrets/passwords.toml: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kernelci/kernelci-project/47dae04e4c76d17b2fad5d1e4b2a0a515d6904c4/secrets/passwords.toml --------------------------------------------------------------------------------