persisting the remote flag

[lkingland]

Summary

We would like to persist the value of --remote, but it clearly does not belong where other persisted values do: on the Function struct. The remote setting should indeed be persisted, but not as part of function state which will affect any environment which checks out function source code (ex: CI/CD environments). Instead, this flag's persistence should be scoped locally: to a single copy of a function (checked out codebase).

Proposed Solution

Store the value of --remote in the persistent, but non-source-controlled .func directory. Subsequent invocations of deploy will retain the vale of --remote, but not interfere with other developers' settings.

Further Discussion

In PR #1079 and its associated issue #1075 we propose creating a dedicated flag (--remote) to indicate if a build/deploy should be handled locally (the default) or via the invocation of a remote Tekton pipeline.

When re-running the deploy command, we seem to agree that the values of flags should persist to the function being operated upon, such that subsequent command repetitions do not require re-setting the flags and mutations of the function are propagated through source control.

In most cases, this is a simple serialization of the function struct. Most of these flags mutate a simple attribute of the Function (adding environment variables, or setting the URL of an associated git repository). The --remote flag, however, is not altering the function's state, but how the func command instantiates and invokes implementations of specific interfaces. It triggers "running in remote mode", but has no effect on the Function itself. Therefore simply adding a .Remote boolean flag to Function to be serialized to disk and stored in source control is not appropriate.

The fact this value has no associated functionality in the core is a further indication that the remote vs local setting is better left unknown to the core and instead used entirely by clients of the core library such as the "cmd" package (func CLI).

This may be illustrated with an example:

Use Case:

• Alice deploys myFunc (all defaults)
• Bob checks out myFunc from source control, makes a bug fix and deploys using --remote. The function is deployed by triggering a remote Tekton task rather than built locally. This flips the "remote" flag in question.
• Bob checks in the new state of the function, which includes this remote flag.
• Aice updates their function source code, makes a small change and runs deploy.
• Bob is now likely confused why the function is not building but instead has triggered some remote task.
• Running deploy again with --remote=false results in a dirty git tree.

This illustrates the problem in a way that hopefully shows there are two questions to be answered. 1) Do we want the func CLI to retain the value of --remote such that subsequent invocations remember this setting? 2) Do we want one user's choice to change the behavior of the environment of another developer?

By answering yes to the first question but no to the second, we may have a viable middle way. Yes, we want the choice to be retained for subsequent command invocations, but perhaps we do not want this setting to be part of the Function's permanent state and to affect other users. The resultant Function artifact is identical if the build/deploy is run locally or triggered in remote.

Making this distinction also alleviates the aforementioned code-smell of adding a .Remote member to the Function struct. The remote flag would not be part of a function's sate, but would rather be part of the forthcoming Config System (see draft PR). The value would be persisted to the non-source-controlled metadata directory ".func", which already includes other stateful, but localhost-scoped settings for a function.

[jrangelramos]

I think this also should (somehow) apply to the git.revision (--git-branch). Currently it is stored in func.yaml, but that can be just one particular user choice that wants to try out a specific revision, tag, or its feature branch, and don't want that to be the part of the function state.

Following the same example cases as below:

• Bob is working on a new feature in this branch bob/feature-b. He triggers build using --git-branch bob/feature-b
• He is happy with the changes and push the code as well
• Alice may pull the changes to try it out and figure out that when she triggers a remote build it will by default built bob's branch instead of the main one.

The same might be valid too in case git.url is already pre-populated on func.yaml and Bob is attempting to build/deploy from his fork (using --git-url from command line). In case deploy succeed func override func.yaml with bob's fork, and he may push. Probably values passed from flags related to git should not be persisted on func.yaml unless they are not set yet.

[lance]

/unassign

[lance]

/unassign @lkingland

[vyasgun]

/assign

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no activity. It will automatically close after 30 more days of inactivity. Reopen the issue with /reopen. Mark the issue as fresh by adding the comment /remove-lifecycle stale.

[lkingland]

/remove-lifecycle stale

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no activity. It will automatically close after 30 more days of inactivity. Reopen the issue with /reopen. Mark the issue as fresh by adding the comment /remove-lifecycle stale.

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no activity. It will automatically close after 30 more days of inactivity. Reopen the issue with /reopen. Mark the issue as fresh by adding the comment /remove-lifecycle stale.