Migrate CI from Travis to GitHub Actions (6.x branch)
Scope of this issue
This issue covers exactly one branch of this plugin: 6.x.
All work in the PR you open from this issue must target the 6.x branch and only 6.x. Other active branches of this plugin are tracked in separate issues — do not touch them here.
Plugin context (use this to render the workflow file correctly):
- Repository default branch:
main
- All active branches of this plugin:
6.x, main
- This issue's target branch:
6.x (default branch? no)
Primary goal
Every test currently run by .travis.yml on the 6.x branch MUST also run in GitHub Actions after this change. That is the single criterion for success. Read the .travis.yml on 6.x carefully (including any matrix.include, env matrices, and jobs.include entries) and make sure every combination has an equivalent GHA job. Do not silently drop matrix entries.
Context
The logstash-plugins/.ci repository now hosts shared reusable GitHub Actions workflows that replace the old Travis-based setup. Two pilot plugins have already been migrated and are the canonical examples to follow:
The shared reusable workflows live here and are what your new workflow files must call. The canonical branch is 1.x — always use @1.x as the ref:
logstash-plugins/.ci/.github/workflows/unit-tests.yml@1.x — unit tests
logstash-plugins/.ci/.github/workflows/integration-tests.yml@1.x — integration tests
logstash-plugins/.ci/.github/workflows/secure-integration-tests.yml@1.x — secure integration tests
logstash-plugins/.ci/.github/workflows/performance.yml@1.x — performance tests
Read the source of those reusable workflows here so you know what inputs they accept and what matrices they already define: https://github.com/logstash-plugins/.ci/tree/1.x/.github/workflows. The reusable workflows already handle the elastic-stack-version / snapshot matrix — do not redefine that matrix in this repo; just call the reusable workflow.
The reference POC issue and PR (filter-grok, unit-only case):
What to do
1. Inspect .travis.yml (follow every import:)
Determine which test types this plugin actually runs — do not guess, do not assume. The file system is the source of truth.
Many plugin .travis.yml files contain nothing but an import: directive pointing at a shared config in logstash-plugins/.ci, for example:
import:
- logstash-plugins/.ci:travis/travis.yml@1.x
When you see import:, you must fetch the imported file and read it (and recursively any files it imports). The imported file is what defines the matrix — the local .travis.yml by itself tells you nothing. Use the shared .ci repo on disk if it's available, or fetch via https://raw.githubusercontent.com/logstash-plugins/.ci/<ref>/<path>.
Only after you have the fully-resolved Travis matrix in front of you, map each test type to a GHA workflow file you need to add:
| Travis signal (in the fully-resolved config) |
Add this workflow file |
| Base matrix runs unit tests (always true) |
.github/workflows/unit-tests.yml calling unit-tests.yml |
INTEGRATION=true in any matrix env |
.github/workflows/integration-tests.yml calling integration-tests.yml |
SECURE_INTEGRATION=true in any matrix env |
.github/workflows/secure-integration-tests.yml calling secure-integration-tests.yml |
HAS_PERFORMANCE_TESTS=1 or a _performance job entry |
.github/workflows/performance.yml calling performance.yml |
If a test type does not appear in the resolved Travis matrix, do not add a workflow for it. Adding workflows that the plugin never ran under Travis is a failure, not a feature.
Only add the workflow files for test types this plugin actually runs. If .travis.yml does not exercise integration tests, do not add an integration workflow.
2. Add the consumer workflow file(s)
Schedule durability — read this first. A GitHub Actions schedule: trigger only fires from the workflow file on the default branch (main), and by default the scheduled run only exercises the default branch's code. A schedule: block on a non-default branch's workflow file is silently dead. To get nightly coverage of every active branch, the default-branch workflow file uses a scheduled job with a matrix over all active branches that passes ref to the reusable workflow. Non-default branches' workflow files only carry push/pull_request triggers; they rely on the default branch's scheduled matrix for cron coverage.
Use exactly this YAML for the unit-tests consumer workflow on this branch (6.x). The shape differs depending on whether this issue's target branch is the default branch:
name: Unit Tests
on:
push:
branches: ['6.x']
pull_request:
branches: ['6.x']
workflow_dispatch:
# Scheduled (cron) coverage for this branch lives in the workflow file on
# the default branch (main); it fans out across every active
# branch via a matrix. Do not add a schedule: block here — it would be
# silently ignored on non-default branches.
jobs:
tests:
uses: logstash-plugins/.ci/.github/workflows/unit-tests.yml@1.x
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: ${{ github.ref != 'refs/heads/6.x' }}
with:
timeout-minutes: 60
For integration / secure integration / performance workflows you add, copy the same shape and swap name and the uses: target (integration-tests.yml@1.x, secure-integration-tests.yml@1.x, performance.yml@1.x) plus any inputs the reusable workflow accepts. The on-block, jobs structure, and matrix logic stay identical.
Note on the ref input to reusable workflows. The scheduled matrix job passes ref: ${{ matrix.branch }} to the reusable workflow so it checks out the right branch. The reusable workflows on logstash-plugins/.ci@1.x already accept this ref input (default '' — no-op for non-scheduled callers).
timeout-minutes should reflect the plugin's actual needs — start with what .travis.yml uses, or 60 if unspecified.
3. Update README.md status badges (on 6.x)
This is required. Replace any Travis badge with the equivalent GitHub Actions badges — one per workflow file you added. Add ?branch=6.x to each badge URL so the badge reflects the status of this branch specifically.
Replace lines that look like:
[](https://travis-ci.com/logstash-plugins/logstash-input-beats)
With one badge per added workflow, e.g.:
[](https://github.com/logstash-plugins/logstash-input-beats/actions/workflows/unit-tests.yml)
[](https://github.com/logstash-plugins/logstash-input-beats/actions/workflows/integration-tests.yml)
[](https://github.com/logstash-plugins/logstash-input-beats/actions/workflows/secure-integration-tests.yml)
Reference: logstash-plugins/logstash-output-elasticsearch#1257.
If the README has no Travis badge at all, add the GHA badge(s) near the top of the file (above the description, matching the convention used in other plugins).
4. Delete .travis.yml
Remove .travis.yml from the repository as part of this PR. Also remove any other Travis-only files if present (e.g. .travis/). The whole point of this migration is to retire Travis for this plugin.
Before deleting, walk through .travis.yml one more time and convince yourself that every matrix entry, env var, and job is covered by the GHA workflows you added. Include that mapping in the PR description (see below).
Explicitly out of scope
- Do not modify plugin source code, specs, or
Gemfile. If you believe a code change is required, stop and call it out in the PR description instead of making the change.
- Do not change the default branch, repo settings, or any other workflow files beyond what is described above.
Branch / PR requirements
The PR must be raised from a branch in the logstash-plugins/logstash-input-beats repository itself, not from a fork. GitHub Actions secrets and reusable-workflow access are not granted to fork-based PRs, so workflows will not run if the PR comes from a fork. Push your working branch directly to logstash-plugins/logstash-input-beats and open the PR from there.
The PR base branch must be 6.x. This issue was assigned with agentAssignment.baseRef = 6.x, so your working branch should already be cut from 6.x. When opening the PR, pass --base explicitly to be safe:
gh pr create --base 6.x --head <your-branch> --title "..." --body "..."
After opening the PR, verify the base branch is correct: gh pr view <number> --json baseRefName must report 6.x. If it shows anything else, fix it with gh pr edit <number> --base 6.x before requesting review.
PR description must include
- Confirmation that the PR targets the
6.x branch, and a link back to this issue.
- A table mapping each
.travis.yml matrix entry / env combination to the corresponding GHA job(s), demonstrating full parity on 6.x.
- The list of new workflow files added.
- The README badge changes.
- Confirmation that
.travis.yml (and any other Travis files) has been deleted on 6.x.
Migrate CI from Travis to GitHub Actions (
6.xbranch)Scope of this issue
This issue covers exactly one branch of this plugin:
6.x.All work in the PR you open from this issue must target the
6.xbranch and only6.x. Other active branches of this plugin are tracked in separate issues — do not touch them here.Plugin context (use this to render the workflow file correctly):
main6.x,main6.x(default branch? no)Primary goal
Every test currently run by
.travis.ymlon the6.xbranch MUST also run in GitHub Actions after this change. That is the single criterion for success. Read the.travis.ymlon6.xcarefully (including anymatrix.include,envmatrices, andjobs.includeentries) and make sure every combination has an equivalent GHA job. Do not silently drop matrix entries.Context
The
logstash-plugins/.cirepository now hosts shared reusable GitHub Actions workflows that replace the old Travis-based setup. Two pilot plugins have already been migrated and are the canonical examples to follow:logstash-integration-kafkalogstash-output-elasticsearchThe shared reusable workflows live here and are what your new workflow files must call. The canonical branch is
1.x— always use@1.xas the ref:logstash-plugins/.ci/.github/workflows/unit-tests.yml@1.x— unit testslogstash-plugins/.ci/.github/workflows/integration-tests.yml@1.x— integration testslogstash-plugins/.ci/.github/workflows/secure-integration-tests.yml@1.x— secure integration testslogstash-plugins/.ci/.github/workflows/performance.yml@1.x— performance testsRead the source of those reusable workflows here so you know what inputs they accept and what matrices they already define: https://github.com/logstash-plugins/.ci/tree/1.x/.github/workflows. The reusable workflows already handle the elastic-stack-version / snapshot matrix — do not redefine that matrix in this repo; just call the reusable workflow.
The reference POC issue and PR (filter-grok, unit-only case):
What to do
1. Inspect
.travis.yml(follow everyimport:)Determine which test types this plugin actually runs — do not guess, do not assume. The file system is the source of truth.
Many plugin
.travis.ymlfiles contain nothing but animport:directive pointing at a shared config inlogstash-plugins/.ci, for example:When you see
import:, you must fetch the imported file and read it (and recursively any files it imports). The imported file is what defines the matrix — the local.travis.ymlby itself tells you nothing. Use the shared.cirepo on disk if it's available, or fetch viahttps://raw.githubusercontent.com/logstash-plugins/.ci/<ref>/<path>.Only after you have the fully-resolved Travis matrix in front of you, map each test type to a GHA workflow file you need to add:
.github/workflows/unit-tests.ymlcallingunit-tests.ymlINTEGRATION=truein any matrix env.github/workflows/integration-tests.ymlcallingintegration-tests.ymlSECURE_INTEGRATION=truein any matrix env.github/workflows/secure-integration-tests.ymlcallingsecure-integration-tests.ymlHAS_PERFORMANCE_TESTS=1or a_performancejob entry.github/workflows/performance.ymlcallingperformance.ymlIf a test type does not appear in the resolved Travis matrix, do not add a workflow for it. Adding workflows that the plugin never ran under Travis is a failure, not a feature.
Only add the workflow files for test types this plugin actually runs. If
.travis.ymldoes not exercise integration tests, do not add an integration workflow.2. Add the consumer workflow file(s)
Schedule durability — read this first. A GitHub Actions
schedule:trigger only fires from the workflow file on the default branch (main), and by default the scheduled run only exercises the default branch's code. Aschedule:block on a non-default branch's workflow file is silently dead. To get nightly coverage of every active branch, the default-branch workflow file uses a scheduled job with a matrix over all active branches that passesrefto the reusable workflow. Non-default branches' workflow files only carrypush/pull_requesttriggers; they rely on the default branch's scheduled matrix for cron coverage.Use exactly this YAML for the unit-tests consumer workflow on this branch (
6.x). The shape differs depending on whether this issue's target branch is the default branch:For integration / secure integration / performance workflows you add, copy the same shape and swap
nameand theuses:target (integration-tests.yml@1.x,secure-integration-tests.yml@1.x,performance.yml@1.x) plus any inputs the reusable workflow accepts. The on-block, jobs structure, and matrix logic stay identical.Note on the
refinput to reusable workflows. The scheduled matrix job passesref: ${{ matrix.branch }}to the reusable workflow so it checks out the right branch. The reusable workflows onlogstash-plugins/.ci@1.xalready accept thisrefinput (default''— no-op for non-scheduled callers).timeout-minutesshould reflect the plugin's actual needs — start with what.travis.ymluses, or 60 if unspecified.3. Update
README.mdstatus badges (on6.x)This is required. Replace any Travis badge with the equivalent GitHub Actions badges — one per workflow file you added. Add
?branch=6.xto each badge URL so the badge reflects the status of this branch specifically.Replace lines that look like:
With one badge per added workflow, e.g.:
Reference: logstash-plugins/logstash-output-elasticsearch#1257.
If the README has no Travis badge at all, add the GHA badge(s) near the top of the file (above the description, matching the convention used in other plugins).
4. Delete
.travis.ymlRemove
.travis.ymlfrom the repository as part of this PR. Also remove any other Travis-only files if present (e.g..travis/). The whole point of this migration is to retire Travis for this plugin.Before deleting, walk through
.travis.ymlone more time and convince yourself that every matrix entry, env var, and job is covered by the GHA workflows you added. Include that mapping in the PR description (see below).Explicitly out of scope
Gemfile. If you believe a code change is required, stop and call it out in the PR description instead of making the change.Branch / PR requirements
The PR must be raised from a branch in the
logstash-plugins/logstash-input-beatsrepository itself, not from a fork. GitHub Actions secrets and reusable-workflow access are not granted to fork-based PRs, so workflows will not run if the PR comes from a fork. Push your working branch directly tologstash-plugins/logstash-input-beatsand open the PR from there.The PR base branch must be
6.x. This issue was assigned withagentAssignment.baseRef = 6.x, so your working branch should already be cut from6.x. When opening the PR, pass--baseexplicitly to be safe:After opening the PR, verify the base branch is correct:
gh pr view <number> --json baseRefNamemust report6.x. If it shows anything else, fix it withgh pr edit <number> --base 6.xbefore requesting review.PR description must include
6.xbranch, and a link back to this issue..travis.ymlmatrix entry / env combination to the corresponding GHA job(s), demonstrating full parity on6.x..travis.yml(and any other Travis files) has been deleted on6.x.