Deploy catalog from CI

[dimaryaz]

No description provided.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (66f73be) 36.23% compared to head (b859d97) 36.23%.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #3872   +/-   ##
=======================================
  Coverage   36.23%   36.23%           
=======================================
  Files         716      716           
  Lines       31618    31618           
  Branches     4688     4688           
=======================================
  Hits        11457    11457           
  Misses      19005    19005           
  Partials     1156     1156           

Flag	Coverage Δ
api-python	91.54% <ø> (ø)
catalog	10.63% <ø> (ø)
lambda	87.52% <ø> (ø)

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.

[dimaryaz]

I'm intentionally pushing only to ECR, not S3. S3 is only used for RODA - and updating RODA is such a manual process that I don't think there's any benefit in slowing down CI for that.

[sir-sigurd]

I'm intentionally pushing only to ECR, not S3. S3 is only used for RODA - and updating RODA is such a manual process that I don't think there's any benefit in slowing down CI for that.

well, yes
though I think we want to make it automated one day, so I'm not sure we should make it more manual
but actually do we really know that using CloudFront for it is really something useful for us?

[nl0]

actually do we really know that using CloudFront for it is really something useful for us?

@sir-sigurd i'd vote for getting rid of this discrepancy and keeping a single deployment / serving approach for the sake of simplicity. i doubt it very much serving w/ nginx would be a perf bottleneck. maybe we would save a couple $ tho, idk. @akarve wdyt?

[nl0]

shouldn't it depend on the tests passing?

[dimaryaz]

shouldn't it depend on the tests passing?

Well, that's why I wanted to split everything up in #3866 - but that looks more complicated than I expected.

But in any case, if we already require tests to pass before merging into master, then I don't think there's much point in running tests again in master.

[dimaryaz]

But does this do anything by itself, without the cache-dependency-path? From the docs, it sounds like it will only look for package-lock.json in the root directory, and not in catalog/package-lock.json.

[nl0]

But does this do anything by itself, without the cache-dependency-path?

i assumed that it would just never invalidate the cache, but that turned out wrong. i fixed it by bringing back catalog/package-lock.json

[akarve]

actually do we really know that using CloudFront for it is really something useful for us?

@sir-sigurd i'd vote for getting rid of this discrepancy and keeping a single deployment / serving approach for the sake of simplicity. i doubt it very much serving w/ nginx would be a perf bottleneck. maybe we would save a couple $ tho, idk. @akarve wdyt?

I see this is merged but I support at least trying to remove the CloudFront special casing for open b/c I agree it's complex. The CDN probably does help SEO scores (page load times) but how much I don't know. Worth measuring the perf difference, as I don't think we ever did. And even if nginx ends up slower maybe we can just scale up those container services.