RFC: Rethinking the "restart" pipeline behavior

[pat-s]

Currently, hitting the "restart" button restarts the respective pipeline while keeping all components static: config, secrets, etc.

This also means, if the pipeline failed for some missing secrets in WP which were specified in the YAML, it will continue to error, even if the secret has been added in the meantime.

To me, this feals a bit unintuitive and I also think most other CIs work differently. I.e. they aim to operate on the same git commit, but try to sync/update all related assets such as secrets etc.

We had this confusion multiple times already on the CB instance where users did not understand why hitting "restart" didn't result in a new clean build but instead they were required to push a new commit (which always works as it resources the whole env incl. secrets) or a manual builds.

My proposal would be to refactor the "restart" button to resource the environment and only keep reusing the same git source of the restarted pipeline in question.

On the flip-side one could argue that this is even a feature as it enables full reproducibility, for the good and bad. Yet I think that (almost) all other CIs work differently, causing wrong user expectations.

Opinions?

👍️: keep current behavior
👎️: refactor

[xoxys]

Are you really sure? Adding the secret later on was definetly working for me (as long as the from_secret ref exists already in the wp config and the spelling is correct).

[pat-s]

Yup, just reproduced this exact scenario on next.

It also appears in the same way if the secret exists but doesn't have appropriate event permissions.

[xoxys]

Tested it on my own now. The secret is not the problem, the real issue is that the pipeline definition is not found if a run is restarted that was not able to start due to missing secrets.

[xoxys]

This is a duplicated of #2982

[pat-s]

Good find. I opened this thread here today after an early investigation of the "pipeline not found error" but initially didn't see that connection. But that might still apply to the general idea here to "resource" the whole config instead of just reloading a possibly failed one (which is what I think is happening right now and causing the overall behaviour described here).

[pat-s]

Related: #2759, #2753, #2982