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
On some platforms, such as TeamCity, vip-go-ci can be executed multiple times per commit, and the platform does not have support for disabling such behavior (see support ticket here). The multiple executions occur in settings such as when the same commit is part of many GitHub Pull-Requests. In these kind of scenarios, it would be best to have support for preventing multiple executions natively within vip-go-ci, via some kind of lock mechanism.
Multiple executions can cause some issues. For instance, the same Pull-Request can be approved multiple times. Also, the same PHPCS issues could be posted multiple times.
It should be possible to have the same commit a part of many Pull-Requests without seeing any issues. This is something that vip-go-ci should support natively and should be an optional feature.
A possible solution
Inserting data and looking for data in a database table can potentially achieve this. Here is an example of three processes that are started for the same commit-ID:
vip-go-ci process A starts, inserts a row into a database table; the row includes the commit-ID and repository information, and identification of itself
vip-go-ci process B starts, inserts a row into a database table; same kind of information as above
A and B check for entries, both find entries. The first process that inserts data does the processing, the other quits. The result is that one process completes the processing of the commit. The data inserted above is not deleted when the processes quit.
Yet another process, C, starts. It inserts a row, similar to 2), then checks and finds existing rows, and quits.
24 hours pass, data older than 12 hours are deleted.
Doing this is quite simple, requires relatively little in terms of software and setup, but should achieve the results desired. The whole process cleans up after itself.
The database is more desirable than a simple lock file, because multiple processes can be launched on different servers that do not share a file-system, but can access the same database.
The text was updated successfully, but these errors were encountered:
On some platforms, such as TeamCity,
vip-go-ci
can be executed multiple times per commit, and the platform does not have support for disabling such behavior (see support ticket here). The multiple executions occur in settings such as when the same commit is part of many GitHub Pull-Requests. In these kind of scenarios, it would be best to have support for preventing multiple executions natively withinvip-go-ci
, via some kind of lock mechanism.Multiple executions can cause some issues. For instance, the same Pull-Request can be approved multiple times. Also, the same PHPCS issues could be posted multiple times.
It should be possible to have the same commit a part of many Pull-Requests without seeing any issues. This is something that
vip-go-ci
should support natively and should be an optional feature.A possible solution
Inserting data and looking for data in a database table can potentially achieve this. Here is an example of three processes that are started for the same commit-ID:
vip-go-ci
process A starts, inserts a row into a database table; the row includes the commit-ID and repository information, and identification of itselfvip-go-ci
process B starts, inserts a row into a database table; same kind of information as aboveDoing this is quite simple, requires relatively little in terms of software and setup, but should achieve the results desired. The whole process cleans up after itself.
The database is more desirable than a simple lock file, because multiple processes can be launched on different servers that do not share a file-system, but can access the same database.
The text was updated successfully, but these errors were encountered: