Details
New Feature
Resolved
Major
Description
As the infrastructure used during the contest preparation phase may be based on git (for example, OI currently is), it would be nice to have automatic deployment.
My idea is to link the master branch in gitlab with SIO2, so that the contest always contains the latest content of the master branch. We want to avoid manual management of packages, as to avoid potential mistakes.
I believe that simplest realization is to create one "shareable" link per task to upload packages. Link works like "reupload package", so it cannot affect other tasks or create a new one.
API should be easy to connect with CI (like GitLab CI).
Access to CI may have more persons than to SIO contest!
Link revoking would be nice.
My idea is to link the master branch in gitlab with SIO2, so that the contest always contains the latest content of the master branch. We want to avoid manual management of packages, as to avoid potential mistakes.
I believe that simplest realization is to create one "shareable" link per task to upload packages. Link works like "reupload package", so it cannot affect other tasks or create a new one.
API should be easy to connect with CI (like GitLab CI).
Access to CI may have more persons than to SIO contest!
Link revoking would be nice.
Activity
- All
- Comments
- History
- Activity
- Transitions
- Commits
I agree with you.
We do have package building in SINOL3 OI-CI. We can handle everything from above from the CI's site.
And yes, we do have one repo per task. This is expected workflow with every git-based system.
> Submit the new package using a HTTP request.
We need specific link to do that.
> 5. Rejudge is triggered on all submissions. (should it be triggered?)
No, expected behavior should be same as with reupload package.
> - limit changes to the task from SIO2 so an CI update won't undo changes (You should only make changes in repo)
That would be amazing.
> - make the git commit hash visible on SIO2
Very good idea.
Thank you for your time.
We do have package building in SINOL3 OI-CI. We can handle everything from above from the CI's site.
And yes, we do have one repo per task. This is expected workflow with every git-based system.
> Submit the new package using a HTTP request.
We need specific link to do that.
> 5. Rejudge is triggered on all submissions. (should it be triggered?)
No, expected behavior should be same as with reupload package.
> - limit changes to the task from SIO2 so an CI update won't undo changes (You should only make changes in repo)
That would be amazing.
> - make the git commit hash visible on SIO2
Very good idea.
Thank you for your time.
Show
Dominik Klemba
added a comment - - edited I agree with you.
We do have package building in SINOL3 OI-CI. We can handle everything from above from the CI's site.
And yes, we do have one repo per task. This is expected workflow with every git-based system.
> Submit the new package using a HTTP request.
We need specific link to do that.
> 5. Rejudge is triggered on all submissions. (should it be triggered?)
No, expected behavior should be same as with reupload package.
> - limit changes to the task from SIO2 so an CI update won't undo changes (You should only make changes in repo)
That would be amazing.
> - make the git commit hash visible on SIO2
Very good idea.
Thank you for your time.
Dominik Klemba
added a comment - - edited I agree with you.
We do have package building in SINOL3 OI-CI. We can handle everything from above from the CI's site.
And yes, we do have one repo per task. This is expected workflow with every git-based system.
> Submit the new package using a HTTP request.
We need specific link to do that.
> 5. Rejudge is triggered on all submissions. (should it be triggered?)
No, expected behavior should be same as with reupload package.
> - limit changes to the task from SIO2 so an CI update won't undo changes (You should only make changes in repo)
That would be amazing.
> - make the git commit hash visible on SIO2
Very good idea.
Thank you for your time. OK, I will work on this after forum changes.
Show
Artur Puzio
added a comment - OK, I will work on this after forum changes.
Artur Puzio
added a comment - OK, I will work on this after forum changes. Thank you very much. I will be grateful.
Show
Dominik Klemba
added a comment - Thank you very much. I will be grateful.
Dominik Klemba
added a comment - Thank you very much. I will be grateful. This issue has been automatically closed as Obsolete due to no activity for 365 days.
Feel free to reopen it or create a new one if it's still relevant.
Feel free to reopen it or create a new one if it's still relevant.
Show
Szymon Acedański
added a comment - This issue has been automatically closed as Obsolete due to no activity for 365 days.
Feel free to reopen it or create a new one if it's still relevant.
Szymon Acedański
added a comment - This issue has been automatically closed as Obsolete due to no activity for 365 days.
Feel free to reopen it or create a new one if it's still relevant. 
- Use Gitlab CI to build the package
- Have only one repository per task
- Submit the new package using a HTTP request.
So the process would be as follows:
Setup:
1. Create "CI" task on SIO2 instance. Copy the update URL and upload KEY.
2. Create repository with GitlabCI and our deployment CI config.
3. Put the URL and KEY to in Gitlab CI Variables.
Update behavior:
1. CI is trigger by new commit on master.
2. CI builds package.
3. CI pushes package by a HTTP request to SIO2
4. SIO2 updates the task
5. Rejudge is triggered on all submissions. (should it be triggered?)
We should also:
- limit changes to the task from SIO2 so an CI update won't undo changes (You should only make changes in repo)
- make the git commit hash visible on SIO2