fix: docker-compose point to master tag

[dpgaspar]

SUMMARY

We now use master and master-dev for latest master tags. This proposes a small change that will probably help people here: #26997 combined with #27146

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TESTING INSTRUCTIONS

ADDITIONAL INFORMATION

• Has associated issue:
• Required feature flags:
• Changes UI
• Includes DB Migration (follow approval process in SIP-59)
  • Migration is atomic, supports rollback & is backwards-compatible
  • Confirm DB migration upgrade and downgrade tested
  • Runtime estimates and downtime expectations provided
• Introduces new feature or API
• Removes existing feature or API

[eschutho]

I think it makes sense to have devs work from master, but for production, wouldn't it be better for them to work from an official release tag?

[dpgaspar]

prob, if that's what's expected

[sfirke]

Agreed with @eschutho - I don't understand all of #26997 but it seems like these people are all trying to run latest builds off master instead of an official release? Or using a mismatch of master repo clone + an official release. Which underscores for me the value of directing new users to an official release instead of master, so that they have a positive experience right out of the box.

[sfirke]

See also my comment here: #26997 (comment)

[dpgaspar]

agree, just checked, and docker-compose-non-dev does not mount the current code so latest is probably the best tag option here.

[mistercrunch]

Awesome. I just merged #27146 which should make the master builds to also be multi-platform, meaning this should work and it will support Apple silicon.

But note that there's something loose here, where it looks like the assumption with docker-compose is that you can mount the code on your local master with the latest master image build and things should just work. That's not super solid/guaranteed. You could be on an older commit that say assumes a python req that's been removed on the latest master. Or you could be ahead of master, introduce a new python req, and for it now be reflected on the image.

Knowing this, should we set docker-compose to "docker build" from the Dockerfile and simply leverage the caching?

[dpgaspar]

Awesome. I just merged #27146 which should make the master builds to also be multi-platform, meaning this should work and it will support Apple silicon.

But note that there's something loose here, where it looks like the assumption with docker-compose is that you can mount the code on your local master with the latest master image build and things should just work. That's not super solid/guaranteed. You could be on an older commit that say assumes a python req that's been removed on the latest master. Or you could be ahead of master, introduce a new python req, and for it now be reflected on the image.

Knowing this, should we set docker-compose to "docker build" from the Dockerfile and simply leverage the caching?

that's a valid point, I guess it depends on how much time it would normally take to build vs the frequency of master requirements being off.

How can we leverage caching when docker-compose build points to Dockerfile?
There must be a way

[mistercrunch]

How can we leverage caching when docker-compose build points to Dockerfile?

I think it should leverage cached layers if pointed to the right cache that supports the master builds (apache/superset-cache). In theory a build that doesn't touch the dependencies should be really fast. I proposed something on #26997 (comment)