The AAS apps haven't been updating correctly, as the dev package versions were not monotonically increasing.
Finally narrowed this down to be how we're generating the buildId - take the workflowID 8277249206 and drop the most significant value. Which clearly has been causing issues when it rolls over 🙄
The reason for this approach is that the workflow ID is too large to fit in an int. So taken a different approach, using the current epoch time (in seconds) instead. That will do us for 10 years, and there's a simple fix subsequently (bump the minor and decrement by int.MaxValue)
Could do with adding checks to the response of the update command to verify it contains the expected version number, but this solves the immediate issue
The AAS apps haven't been updating correctly, as the dev package versions were not monotonically increasing.
Finally narrowed this down to be how we're generating the buildId - take the workflowID
8277249206and drop the most significant value. Which clearly has been causing issues when it rolls over 🙄The reason for this approach is that the workflow ID is too large to fit in an
int. So taken a different approach, using the current epoch time (in seconds) instead. That will do us for 10 years, and there's a simple fix subsequently (bump the minor and decrement byint.MaxValue)Did a test run with it here, and all looks good to me: https://github.com/DataDog/datadog-aas-extension/actions/runs/8278055022/job/22649631769
Could do with adding checks to the response of the update command to verify it contains the expected version number, but this solves the immediate issue