Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prevent multiple execution per commit natively #77

Open
gudmdharalds opened this issue Jan 22, 2020 · 0 comments
Open

Prevent multiple execution per commit natively #77

gudmdharalds opened this issue Jan 22, 2020 · 0 comments

Comments

@gudmdharalds
Copy link
Contributor

gudmdharalds commented Jan 22, 2020

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:

  1. 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
  2. vip-go-ci process B starts, inserts a row into a database table; same kind of information as above
  3. 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.
  4. Yet another process, C, starts. It inserts a row, similar to 2), then checks and finds existing rows, and quits.
  5. 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant