[hlx deploy] must run hlx build

[kptdobe]

Is your feature request related to a problem? Please describe.
While setting up my production environment and fixing some bugs, I had to run deploy multiple times. Even though I test with hlx up before running the hlx deploy, the build is not up-to-date and I keep forgetting to run hlx build. Testing on production is pretty slow, thus I keep losing time understanding why my changes did not have the expected result. The only reason is that the code is not live... Error prone and quite frequent.

Describe the solution you'd like
hlx deploy should either run a hlx build for me. Telling me the build is not up to date would not be a good option because I never want to deploy an older version... (I could still checkout the old code if really needed)

Describe alternatives you've considered
N/A

[tripodsan]

hlx up does exactly the same thing as helix build. so I don't understand why this makes a difference.

but I agree. I think we can add a forced build before each deploy. maybe with an extra flag to disable if one like: --no-build

[trieloff]

Should we also add a forced deploy before strain?

[tripodsan]

Should we also add a forced deploy before strain?

no. strains and actions are not related.

[tripodsan]

@lkrapf had this issue, too....

[bdelacretaz]

I was also hit bit this today in adobe/helix-test-content-onedrive-auth#2 - pinging the developer experience theme, adobe/helix-home#40 to link this issue there.

[rofe]

I understand the goal here is that developers shouldn't have to remember to run hlx build. I looked into the code a bit, and I think instead of triggering build from deploy and adding a new argument to control it there, we should actually have package trigger build:

package should probably never run without (or with outdated) scripts anyway. And deploy already supports an argument determining if packages should be (re)built before deploying. I think it would make sense to piggy-back on this argument instead of adding a potentially conflicting/nonsensical --no-build. So when running deploy, build would always be triggered implicitly through package, unless you call hlx deploy --package=ignore.

If we should ever feel that developers must still be able to avoid (re)building for whatever reason, we could e.g.:

• add a --no-build argument to package, and some 4th option to deploy --package=..., or
• keep a timestamp of last package creation and skip the build step if the last modified dates of scripts are older