If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)
It is hard to see from the outside whether a Stack object is responding to changes you've made. For example, whether it has seen, and is running, new code you've committed. At present, only the last state reached is shown; so if it goes from success to success with a new source revision, you won't see any change.
The obvious way to improve this is to use additionalPrinterColumns so that kubectl get stack will show a summary of the state, including when it's processing. The Ready/Reconciling/Stalled conditions give enough info to show what's happening at the time of asking; they may need to be summarised in a new .status field for it to be usable in additionalPrinterColumns.
The revision under processing would also be useful -- in most cases this will be the last attempted revision, but there may need to be work done to ensure this (and .lastSuccessfulCommit) is kept accurate.
It is hard to see from the outside whether a Stack object is responding to changes you've made. For example, whether it has seen, and is running, new code you've committed. At present, only the last state reached is shown; so if it goes from success to success with a new source revision, you won't see any change.
The obvious way to improve this is to use
additionalPrinterColumnsso thatkubectl get stackwill show a summary of the state, including when it's processing. The Ready/Reconciling/Stalled conditions give enough info to show what's happening at the time of asking; they may need to be summarised in a new.statusfield for it to be usable inadditionalPrinterColumns.The revision under processing would also be useful -- in most cases this will be the last attempted revision, but there may need to be work done to ensure this (and .lastSuccessfulCommit) is kept accurate.