• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

astronomer / astro-cli / 38580256031
61%
main: 45%

Build:
Build:
LAST BUILD BRANCH: v2-onbuild-refusal
DEFAULT BRANCH: main
Ran 14 Oct 2026 02:29PM UTC
Jobs 1
Files 333
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

14 Oct 2026 02:24PM UTC coverage: 57.849% (+0.07%) from 57.784%
38580256031

push

github

web-flow
Refuse to convert a 1.x project under an APC context, and give the same advice everywhere (#2285)

* Keep the 1.x build when astro init converts a project that deploys to APC

APC's `astro deploy` builds only the 1.x layout: it requires
.astro/config.yaml and builds the Dockerfile, whose runtime base installs
requirements.txt and packages.txt. Converting a 1.x project kept
.astro/config.yaml but retired a FROM-only Dockerfile and the lists it
migrated, so an APC user's next deploy passed the project check and failed
to build.

When the current context is APC (the platform the root mounts, so the same
answer `astro deploy` gets), init now keeps those three files, undeclared,
writes a .dockerignore for that build's context, and says why under Left to
do. The manifest still carries the pin and both lists, and stays a
generated-build project, so Astro users and `astro local` are unchanged.
Declaring the Dockerfile instead was rejected: it would switch Docker mode
and Astro builds to it and drop the generated build for a constraint only
APC's deploy has.

Co-Authored-By: Claude <noreply@anthropic.com>

* Decide APC from the project first, and make the link, the build and the note agree

Review of the first commit found the APC decision and the deploy link made
apart. With an APC context, a project whose .astro/config.yaml saved a cuid
deployment and workspace kept its 1.x build with an APC note and also got an
Astro link. Houston's ids are cuids too, so that pair cannot say which
platform it names.

Where the project deploys is now settled once, by resolveDeployTarget, and
passed to every decision that depends on it. A saved Software release name
(the 0.x CLI saved one there) means APC whatever the context says. Otherwise
Options.DeploysToAPC, the current context, decides. Under APC the saved
target stays a note instead of an Astro link.

planRetirements now owns the rule. A Dockerfile that will be built, declared
or deployed by APC, keeps requirements.txt... (continued)

197 of 233 new or added lines in 10 files covered. (84.55%)

1 existing line in 1 file now uncovered.

40297 of 69659 relevant lines covered (57.85%)

243.77 hits per line

Uncovered Changes

Lines Coverage ∆ File
21
72.0
internal/project/apc.go
7
54.84
-15.99% cmd/problemkind.go
3
95.56
-0.0% cmd/local/dev.go
3
89.51
-1.92% config/config.go
2
69.79
4.52% cmd/local/initcmd.go

Coverage Regressions

Lines Coverage ∆ File
1
95.56
-0.0% cmd/local/dev.go
Jobs
ID Job ID Ran Files Coverage
1 38580256031.1 14 Oct 2026 02:29PM UTC 333
57.85
GitHub Action Run
Source Files on build 38580256031
  • Tree
  • List 333
  • Changed 9
  • Source Changed 9
  • Coverage Changed 9
Coverage ∆ File Lines Relevant Covered Missed Hits/Line
  • Back to Repo
  • Github Actions Build #38580256031
  • 18b3e951 on github
  • Prev Build on v2 (#38579275172)
  • Next Build on v2 (#38581372048)
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE TRIAL · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc