Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 16 additions & 0 deletions .github/workflows/installer-test.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,16 @@
# Calls the central reusable installer-test workflow.
# Managed by scottconverse/installer-ci; edit there, not here.
name: installer-test
on:
push:
branches: [master]
pull_request:
branches: [master]
workflow_dispatch:
jobs:
installer-test:
uses: scottconverse/installer-ci/.github/workflows/installer-test.yml@main

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Configure installer-ci instead of relying on auto-detect

This calls installer-ci with no inputs, so its default detector will scan the whole monorepo. I checked the referenced workflow: it adds python-pip-wheel for any pyproject.toml, go-binary for any go.mod, and docker-image for any Dockerfile, then its Python step runs python -m build at the checkout root and its Go step defaults to go build ... .. This repo has services/*/pyproject.toml, tray/go.mod, and several subdir Dockerfiles but no root Python package or root Go module (go list . fails), so every PR/push to master will fan out into failing non-installer jobs before testing the actual Windows/macOS/Linux installer scripts. Add repo-specific inputs/support in installer-ci or keep this disabled until the detector can target the real installer build paths.

Useful? React with 👍 / 👎.

permissions:
contents: read
packages: read
secrets: inherit
Loading