Incorrect project build number used in certain scenario

[apulverizer]

Hi @fescobar

We've run into a problem where when calling the generateReport endpoint, it's storing the results in an older build directory instead of incrementing by 1. For example say we have a reports directory in a project of:

108
109
110
latest

We'd expect the next report to be stored in 111. However it is being stored in 109, for example.

What happened is that we changed the directory where we were storing projects and moved it to a new location. When those directories and report files were moved, it altered the last modified time of the directories.

So then when this is called: https://github.com/fescobar/allure-docker-service/blob/351f02893bc88835a21c9fab85005933734bdcd9/allure-docker-scripts/generateAllureReport.sh#L15

It is not returning 110 but is returning 108 which then gets incremented to 109.

Is it possible to actually sort the numeric reports instead of relying on the last modified time?

---

It seems like a workaround for us is to touch the most recent directory within each project.

[fescobar]

Hi @apulverizer when you move your directories do it keeping timestamps

Something like this:

mv --recursive --preserve=timestamps [SOURCE] [DESTINY]

[apulverizer]

@fescobar thanks, if we move the directories again we'll do that. We made an assumption that the max build number was fetched and then incremented so it didn't occur to us that it was based on the modified time.

[fescobar]

@apulverizer I will add documentation about that.

[mkrawc]

I also encounter the same issue. I try to store report outputs on S3 and sync it to a volatile docker container to generate a new reports version. The issue is that Amazon S3 doesn't preserve modification times and all times are set to the time when I upload previous results to S3.

A simple change with sorting would solve the issue:

LAST_REPORT_PATH_DIRECTORY=$(ls $PROJECT_REPORTS/ | sort -n | tail -1)