You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Creating a job-server release with a list of requested files (created the File instance, but doesn't actually upload it)
Calling the job-server upload endpoint for each individual file
We have now updated the job-server releases API so that re-uploads are not blocked. This has (mostly) fixed the issues seen in this thread. However, this release contains 134 files. After the re-upload fixes, some of those files were uploaded on another attempt to release from airlock. It then seems to have encountered an unhandled error which has stopped the last 12 or so files being uploaded. The only solution is to try again to release from Airlock.
There are a few things that would make this experience better:
Have job-server return a non-error message if a file has already been uploaded. Currently it's returning 400s which Airlock catches, but are misleading when looking for problems in honeycomb 2) Check the response from job-server and record on the Airlock ReleaseFileMetadata whether the file has been uploaded or not. This means we can avoid sending every already-uploaded file to job-server again if we need to re-attempt a release 3) Catch errors from uploading files so we can retry and/or continue to reupload the remaining files 4) Report something better than "Release failed" in Airlock (if we do Automate deployment to test backend #3 we should be able to report X of Y files were released)
We also have #468 for releasing files asynchronously
#765 will fix #468, which in turn addresses most of points 2-4 above. Still remaining:
Files are released to job-server by
We have now updated the job-server releases API so that re-uploads are not blocked. This has (mostly) fixed the issues seen in this thread. However, this release contains 134 files. After the re-upload fixes, some of those files were uploaded on another attempt to release from airlock. It then seems to have encountered an unhandled error which has stopped the last 12 or so files being uploaded. The only solution is to try again to release from Airlock.
There are a few things that would make this experience better:
2) Check the response from job-server and record on the Airlock ReleaseFileMetadata whether the file has been uploaded or not. This means we can avoid sending every already-uploaded file to job-server again if we need to re-attempt a release3) Catch errors from uploading files so we can retry and/or continue to reupload the remaining files4) Report something better than "Release failed" in Airlock (if we do Automate deployment to test backend #3 we should be able to report X of Y files were released)We also have #468 for releasing files asynchronously
#765 will fix #468, which in turn addresses most of points 2-4 above. Still remaining:
The text was updated successfully, but these errors were encountered: