TEP-0100: PipelineRun Status Migration

[jerop]

TEP-0100: Embedded TaskRuns and Runs Status in PipelineRuns proposed changes to PipelineRun status to reduce the amount of information stored about the status of TaskRuns and Runs to improve performance, reduce memory bloat and improve extensibility.

This feature was released in v0.35.0 gated behind the embedded-status feature flag, and this issue tracks the migration and removal of that feature flag.

• v0.35.0: embedded-status flag defaults to full
• v0.44.0: embedded-status flag defaults to minimal
• v0.45.0: embedded-status flag is removed

[jerop]

06.24 update: we are dogfooding the minimal status in the alpha integration tests

• TEP-0090: Allow setting embedded status feature flag to minimal in tests #5032
• Enable minimal embedded status is alpha integration tests plumbing#1096

[tekton-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale with a justification.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[jerop]

/lifecycle frozen

[afrittoli]

One part of this will be addressed in v0.44, but I think we will only close in v0.45, so perhaps we should move this to that milestone?

[JeromeJu]

One part of this will be addressed in v0.44, but I think we will only close in v0.45, so perhaps we should move this to that milestone?

The TEP100 and this issue shall close only in v0.45, sounds good to me. Thanks @afrittoli

[JeromeJu]

• v0.45.0: embedded-status flag is removed

  • For the changes in v0.45, the test cases with FullEmbeddedStatus shall be removed along with the flag value.
  • The pipelinerun reconciler needs to be updated to not to rely on cfg.featureflags.embeddedstatus
  • Remove the embedded-status feature flags in plumbing repo and decide the sequence.

[JeromeJu]

Updated to implement in a single PR

---

Earlier I drafted up #6049 only to figure out which would be the better practice for implementing the removal of the embedded-status flag for v0.45. And for the purpose of code hygiene and easy rollback for review, I would like to propose separating them into the following:

one pull request for refactoring/ removing all the test cases for pipelineRunStatus with full and both embedded status
one pull request for the integration test cases for removing the requireAnyGate of full or both embedded status
one pull request for changing the reconciler logics and removing the flag
one pull request for changing the embedded-status in the plumbing repo for prow setup

Please let me know if this sounds good cc @abayer @jerop @lbernick. Thanks!

[lbernick]

tektoncd/community#931 is not merged yet, but in it, I added the guidance "Tests and documentation (where applicable) should always be part of the same pull request when introducing a change". To expand on this a bit in this context: If you remove tests first, we now have untested functionality (different values of the feature flag) in our code base. We wouldn't allow someone to introduce functionality without tests, so we should also not allow tests to be removed before the functionality is. The same is true for documentation. In terms of "easy rollback": if there was an issue with removing the feature flag and we wanted to revert the commit removing the flag, we would also want to revert removal of the tests. Therefore, I'd put this all in the same PR.

Changing our prow cluster configuration is a separate repo, so that can happen completely independently.

[JeromeJu]

tektoncd/community#931 is not merged yet, but in it, I added the guidance "Tests and documentation (where applicable) should always be part of the same pull request when introducing a change". To expand on this a bit in this context: If you remove tests first, we now have untested functionality (different values of the feature flag) in our code base. We wouldn't allow someone to introduce functionality without tests, so we should also not allow tests to be removed before the functionality is. The same is true for documentation. In terms of "easy rollback": if there was an issue with removing the feature flag and we wanted to revert the commit removing the flag, we would also want to revert removal of the tests. Therefore, I'd put this all in the same PR.

Changing our prow cluster configuration is a separate repo, so that can happen completely independently.

Makes sense! Thanks Lee, I will stick to the same PR then.

[JeromeJu]

Opened for cleanup after the removal of embedded-status feature flag in v0.45:

• Cleanup for PipelineRunStatus Migration after EmbeddedStatus Feature Flag is removed #6090