rultor
rultor copied to clipboard
yegor256
Build Number
Hey,
we want to use rultor for deploying our project when stuff gets merged to master. However for that we need some unique ID that is guaranteed to be higher than the last time the action was done, some may call this a build number :) Your docs don't really state such a thing exist, at least I didn't find it.
We'd love to switch to rultor for such things, currently we're using CI which is very comfortable but lacks the "pre-merge-security" and simulating deployment steps on wip branches isn't really the same.
@yegor256 that is a very high number and feels somewhat hacky, I'd rather prefer real build numbers.
@sils1297 each "talk" (a Github issue, for example) in rultor has its own number, and each build inside the talk has a number as well. Thus, we have two numbers... We can expose them both to all scripts, like ${talk} and ${build}. What do you think?
@yegor256 sounds good, I assume the build is not unique across talks though? I think people would prefer simplicity, i.e. a simple build number from which in the best case they even can generate an URL to the rultor log. (CircleCI does this.)
@sils1297 yes, each build has a unique number and it's a combination of these two, for example, your build: http://www.rultor.com/t/4513-122032736 Pay attention to the end of the URL. 4513 is the talk number and 122032736 is a unique ID of the build inside the talk. We're using Github message ID for simplicity.
So, a unique address of this build is 4513-122032736
@yegor256 so I guess we have no choice but use the good old time at least on short term.
@sils1297 well, we can add a unique incremental number to the system, which will uniquely identify builds across the entire Rultor. It's not a big problem, but do we need this? Let's think.. How much difference will it have from good old date?
@yegor256
- It's a bit less useful because date actually provides a hidden information.
- It's probably a high number too but probably lower.
- It doesn't feel hacky for your users because they are just using something as intended. (Actually even providing the date in a $BUILD_NUM variable would be better for the usability I think.)
FWIW, the ideal solution would be a number that is only unique per repository IMO. This would then be a real build number.
Just make sure you use the right time, in some time zones theres summer/winter time and stuff that needs to be avoided. Other than that I see no big risks.
@sils1297 attached this issue to milestone "2.0" (let me know if this is wrong)
@yegor256 fyi we ended up using date --utc +%Y%m%d%H%M%S to get the full "meaning" advantage.
@alex-palevsky assign someone else pls
@yegor256 30 points deducted from your rating
@alex-palevsky assign someone else pls
@yegor256 right, I'll try to find someone else for this task
@alex-palevsky this is postponed
@original-brownbear got it, "postponed" label here
@alex-palevsky this is postponed
@original-brownbear someone else will help in this task, no problem at all
