patek/patek.cz
9
0
Fork 0
Code Issues 4 Pull Requests 2 Packages Projects Releases Wiki Activity

All branches share docker container, if you test on one, you break all. #9

New Issue
Open
opened 2020-01-06 20:19:43 +00:00 by Greenscreener · 5 comments
Greenscreener commented 2020-01-06 20:19:43 +00:00 (Migrated from gitlab.com)
Copy Link
No description provided.
vojta001 commented 2020-01-06 22:01:18 +00:00 (Migrated from gitlab.com)
Copy Link

I know, we should fix it somehow. Fortunately though, the current image deploys correctly, only the lint phase fails

I know, we should fix it somehow. Fortunately though, the current image deploys correctly, only the lint phase fails
vojta001 commented 2020-05-18 20:30:19 +00:00 (Migrated from gitlab.com)
Copy Link

Partially solved by !26.

Partially solved by !26.
Greenscreener commented 2020-05-18 21:42:22 +00:00 (Migrated from gitlab.com)
Copy Link

Well not really. If you're testing one branch, you will manually trigger the build anyway (to test if it's working) and if it isn't working you will end up breaking all other deployments. I don't think there's a case where you'd test the docker container and it's building process without triggering the build.

Well not really. If you're testing one branch, you will manually trigger the build anyway (to test if it's working) and if it isn't working you will end up breaking all other deployments. I don't think there's a case where you'd test the docker container and it's building process without triggering the build.
vojta001 commented 2020-05-18 22:01:11 +00:00 (Migrated from gitlab.com)
Copy Link

You're right it is a poor solution, but still worth mentioning IMHO. It also makes the potential breakage much more explicit and obvious.

I don't know what the optimal solution to this problem is. Given half of the commits were triggering the rebuild anyway, we might abandon caching the image completely.

You're right it is a poor solution, but still worth mentioning IMHO. It also makes the potential breakage much more explicit and obvious. I don't know what the optimal solution to this problem is. Given half of the commits were triggering the rebuild anyway, we might abandon caching the image completely.
Greenscreener commented 2020-05-18 22:11:25 +00:00 (Migrated from gitlab.com)
Copy Link

IMHO manual builds are an important part of the solution. The next step might be, that instead of just using the tag "latest", each branch would have it's own tag, and in the lint_build_test stage, it will always use the image with the tag corresponding to the branch. But! If such image doesn't excuse (because the build hasn't yet been manually triggered) it will default to master's. This means, that we can have only the master image and never trigger the build, in such case all branches would default to the master image (which will be exactly the same behaviour as right now, just the name would change). When we'll need to modify the ci in a new branch, we'll just trigger the build on that branch and that branch will automatically use it's own image instead of the master one. Speaking of modifying the images, we might want to change some settings in the linters, as we've started enforcing more strict rules (for instance for whitespace) it would be good if that enforcement would be also done by the linters (that's why we have them).

IMHO manual builds are an important part of the solution. The next step might be, that instead of just using the tag "latest", each branch would have it's own tag, and in the lint_build_test stage, it will always use the image with the tag corresponding to the branch. But! If such image doesn't excuse (because the build hasn't yet been manually triggered) it will default to master's. This means, that we can have only the master image and never trigger the build, in such case all branches would default to the master image (which will be exactly the same behaviour as right now, just the name would change). When we'll need to modify the ci in a new branch, we'll just trigger the build on that branch and that branch will automatically use it's own image instead of the master one. Speaking of modifying the images, we might want to change some settings in the linters, as we've started enforcing more strict rules (for instance for whitespace) it would be good if that enforcement would be also done by the linters (that's why we have them).
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels   
bug

   
easy pick

   
enhancement

   
fixneeded

   
help wanted
No Label
bug
easy pick
enhancement
fixneeded
help wanted
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: patek/patek.cz#9
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?