feat: add pvc-size flag to deploy command (#851)

[grafvonb]

Ref: #851

Second try, after recreating the changes on the new project structure (old PR: #1543)

[grafvonb]

Getting currently a little bit strange panic during an old UT (in previous version it was ok):

--- FAIL: TestDeploy_BuilderPersists (0.01s)
panic: runtime error: invalid memory address or nil pointer dereference [recovered]
	panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x1c38bca]

Needs investigation.

[codecov]

Codecov Report

Patch coverage: 79.41% and project coverage change: +0.21 🎉

Comparison is base (ca24420) 62.71% compared to head (af9a246) 62.93%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1598      +/-   ##
==========================================
+ Coverage   62.71%   62.93%   +0.21%     
==========================================
  Files          93       93              
  Lines       11939    11955      +16     
==========================================
+ Hits         7488     7524      +36     
+ Misses       3770     3751      -19     
+ Partials      681      680       -1     

Flag	Coverage Δ
e2e-test	38.87% <67.64%> (+0.02%)	⬆️
e2e-test-oncluster	34.71% <79.41%> (+<0.01%)	⬆️
e2e-test-oncluster-runtime	29.57% <79.41%> (?)
e2e-test-runtime-go	28.26% <67.64%> (?)
e2e-test-runtime-node	29.40% <67.64%> (?)
e2e-test-runtime-python	29.40% <67.64%> (?)
e2e-test-runtime-quarkus	29.54% <67.64%> (?)
e2e-test-runtime-springboot	28.42% <67.64%> (?)
e2e-test-runtime-typescript	29.54% <67.64%> (?)
integration-tests	49.43% <76.47%> (+0.06%)	⬆️
unit-tests-macos-latest	48.20% <76.47%> (-0.01%)	⬇️
unit-tests-ubuntu-latest	49.16% <76.47%> (+0.01%)	⬆️
unit-tests-windows-latest	48.14% <76.47%> (+0.02%)	⬆️

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

Impacted Files	Coverage Δ
pkg/pipelines/tekton/pipelines_pac_provider.go	4.63% <0.00%> (ø)
pkg/pipelines/tekton/pipeplines_provider.go	57.05% <57.14%> (-0.42%)	⬇️
cmd/deploy.go	75.43% <86.95%> (-0.18%)	⬇️
pkg/functions/function.go	77.92% <100.00%> (+0.17%)	⬆️

... and 2 files with indirect coverage changes

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[matejvasek]

Something is wrong with build timestamps.

[matejvasek]

touch func.yaml && /home/mvasek/devel/kn-plugin-func/func build --path /tmp/test-config-labels --registry localhost:50000/user --builder pack && /home/mvasek/devel/kn-plugin-func/func deploy --path /tmp/test-config-labels --registry localhost:50000/user --build=false -v
   🙌 Function image built: localhost:50000/user/test-config-labels:latest
Error: not built

[matejvasek]

touch func.yaml && /home/mvasek/devel/kn-plugin-func/func build --path /tmp/test-config-labels --registry localhost:50000/user --builder pack && /home/mvasek/devel/kn-plugin-func/func deploy --path /tmp/test-config-labels --registry localhost:50000/user --build=false -v
   🙌 Function image built: localhost:50000/user/test-config-labels:latest
Error: not built

It appears that build sets buildStamp at the end of build but it simultaneously creates .gitignore (which affects final stamp). There is apparently some race because sometimes the modified .gitignore is taken into account and sometime is's not.

I don't see how this PR is causing this.

[matejvasek]

See #1608

[matejvasek]

@grafvonb Now I see similar issue is happening with func.yaml it is also (similarly to .gitignore) modified between build and deploy.

[matejvasek]

@grafvonb Now I see similar issue is happening with func.yaml it is also (similarly to .gitignore) modified between build and deploy.

In deploy step we are updating func.yaml just before running buildStamp. Sometimes the write to FS is delayed so it works sometimes it is fast so stamp is not matching.

[grafvonb]

@grafvonb Now I see similar issue is happening with func.yaml it is also (similarly to .gitignore) modified between build and deploy.

In deploy step we are updating func.yaml just before running buildStamp. Sometimes the write to FS is delayed so it works sometimes it is fast so stamp is not matching.

Can I re-run the pipeline without changing anything or faking with --amend of the last commit?

[matejvasek]

@grafvonb Now I see similar issue is happening with func.yaml it is also (similarly to .gitignore) modified between build and deploy.

In deploy step we are updating func.yaml just before running buildStamp. Sometimes the write to FS is delayed so it works sometimes it is fast so stamp is not matching.

Can I re-run the pipeline without changing anything or faking with --amend of the last commit?

I suppose you could, or you could add empty commit. But I don't think it will pass. If it was single test then maybe, but there are multiple and do not think that odds are high that all test will pass.

[matejvasek]

@grafvonb what is weird is that this happens for this PR. We should see it on pretty much all PRs.

[matejvasek]

Could you look into it more closely?

[matejvasek]

/approve
/lgtm

[grafvonb]

@lance @matejvasek I rebased the commits again and resolved all conflicts. Can we maybe finalize this soon? Since my change touches function.go, the "out of sync" problem will happen again and again....

[grafvonb]

"Analyse" check fails due to:

Errors during downloading metadata for repository 'baseos':
    - Downloading successful, but checksum doesn't match. Calculated: 67f0fad4fe457471c91c70a50245e5700a98c4b49d509d35a8b6643eed55e789b3afb5ced888da13b63a3bdfd122e7aecc8b6c485a9dedcd1afca23cf81fa288(sha512)  Expected: 60642857dc1e825a77340c6ffe13eb4c84f0c3c1972dd4dfc7ab8e00c6b1980f63a5d331bd97f5a9808466c657325a1063[18](https://github.com/knative/func/actions/runs/4615303335/jobs/8159049308?pr=1598#step:2:18)40267e80cfb5a87b1adb28d52947(sha512)

@matejvasek Who can repair this?

[matejvasek]

/approve
/lgtm

[knative-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: grafvonb, matejvasek

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [matejvasek]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment