refactor: rename docker-compose files and update references

[polRk]

SUMMARY

This pull request updates references to Docker Compose configuration files across multiple workflows, documentation, and scripts. The changes standardize the naming of these files from docker-compose*.yml to compose*.yml for consistency.

ADDITIONAL INFORMATION

https://github.com/compose-spec/compose-spec/blob/main/spec.md

[korbit-ai]

I've completed my review and didn't find any issues.

Files scanned

​

File Path	Reviewed
docs/docs/quickstart.mdx	✅
docs/docs/installation/installation-methods.mdx	✅
docs/docs/installation/docker-compose.mdx	✅
docs/docs/configuration/alerts-reports.mdx	✅
docs/docs/contributing/development.mdx	✅
docs/docs/configuration/databases.mdx	✅

Explore our documentation to understand the languages and file types we support and the files we ignore.

Check out our docs on how you can make Korbit work best for you and your team.

Loving Korbit!? Share us on LinkedIn Reddit and X

[github-actions]

Congrats on making your first PR and thank you for contributing to Superset! 🎉 ❤️

We hope to see you in our Slack community too! Not signed up? Use our Slack App to self-register.

[mistercrunch]

I'm not against this renaming, though it's unclear to me if it's a net positive. Tradeoff is things are a bit more intuitive to newcomers and creating a bit of confusion for current devs.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 72.89%. Comparing base (76d897e) to head (64a36e5).
Report is 1987 commits behind head on master.

Additional details and impacted files

@@             Coverage Diff             @@
##           master   #33790       +/-   ##
===========================================
+ Coverage   60.48%   72.89%   +12.40%     
===========================================
  Files        1931      558     -1373     
  Lines       76236    40347    -35889     
  Branches     8568     4238     -4330     
===========================================
- Hits        46114    29411    -16703     
+ Misses      28017     9843    -18174     
+ Partials     2105     1093     -1012     

Flag	Coverage Δ
hive	47.16% <ø> (-1.99%)	⬇️
javascript	?
mysql	71.88% <ø> (?)
postgres	71.94% <ø> (?)
presto	50.93% <ø> (-2.88%)	⬇️
python	72.85% <ø> (+9.35%)	⬆️
sqlite	71.45% <ø> (?)
unit	100.00% <ø> (+42.36%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[polRk]

I'm not against this renaming, though it's unclear to me if it's a net positive. Tradeoff is things are a bit more intuitive to newcomers and creating a bit of confusion for current devs.

Thank you for your feedback!

The main reason for renaming docker-compose.yml to compose.yml is that there are now various solutions, beyond Docker, that support running applications based on the Compose specification. Having "docker" in the file name can mislead some developers, particularly those who don't have access to Docker, into thinking that Docker is a mandatory requirement for running applications, which is not necessarily the case.

Renaming makes the configuration more universal and accessible to a broader range of developers, regardless of the tools they are using.

[mistercrunch]

Oh that makes more sense. What are the alternatives? Any pointers to the latest/greatest packages? Articles to point to about their advantages over docker compose ?

[polRk]

Oh that makes more sense. What are the alternatives? Any pointers to the latest/greatest packages? Articles to point to about their advantages over docker compose ?

Docker Compose indeed works well with the Compose specification and detects compose.y(a)ml files by default. However, there are other tools that also support this specification, including:

• Docker Compose
• Podman Compose
• Kompose
• Nerdctl
• Okteto Stacks
• Docker Cloud Integrations

You can find the full list and additional information on the official Compose specification page: Compose-spec README.

In my changes, I'm not suggesting replacing docker compose .... All documentation remains the same and everything continues to work as before.

[mistercrunch]

Approving but will let a few days before merging to let other committers time to chime in.

[rusackas]

Nobody's chimed in. Merge?

[jbat]

This creates some confusion on the 4.1.2 official release as it appears this doc change is live already.

As per the Quickstart

git checkout tags/4.1.2
docker compose -f compose-image-tag.yml up
superset/compose-image-tag.yml: no such file or directory

4.1.2 release has the yml file still as docker-compose-image-tag.yml

If we are sticking with this compose-image-tag.yml filename change
we may need 2 cmds mentioned in the Quickstart for pre and post namechange

[mistercrunch]

Oh right, the real longer term solution is to publish the versioned docs. I know @rusackas was working on that a little while back.

In the meantime, it'd be great if someone could add a note about this. Here it changes depending on what version you have checked out.

Could also revert...

[polRk]

@jbat Thanks for catching this! You’re right — the filename change in the docs can be confusing for anyone following the Quickstart on the 4.1.2 release, since that version still uses docker-compose-image-tag.yml. The main branch now uses compose-image-tag.yml, so the docs and code are out of sync for older releases.

Until versioned documentation is available, I can add a note to the Quickstart to clarify which filename to use depending on the version. Would that work for you, or would you prefer to revert the doc changes for now? Happy to help either way!

Let me know which approach you prefer — I’m happy to submit a PR with the clarification!

[sfirke]

It will also appear as docker-compose-image-tag.yml to anyone who sets their repo to the 5.0.0 tag: https://github.com/apache/superset/blob/5.0/docs/docs/quickstart.mdx.

We could revert the renaming PR and hold it for the next major release, that way it would hit the repo right before 6.0.0 come out and be included in 6.0.0? That would minimize the amount of time there's a difference between how you run master vs. latest. Though even then we'd want a note about the file name being different for versions <=5.x

[mistercrunch]

So I'd say two options:

• revert until we have versioned docs in place
• clarify the docs with "prior to version N do this, post version N do this"

[sfirke]

I guess let's revert until we get versioned docs? New issues keep coming in about this.

[hainenber]

For now, my vote is on the revert. More folks will feel baffled reading the Quickstart guide.

[hainenber]

yikes, GH doesn't allow creating revert due to newly changes. Had to manually create the PR here, committer folks.