Drone: [Feature Request] Be able to set a starting build number

[josmo]

It would be great to be able to set the starting build number.

Use case:
When you migrate from another build system or even upgrade drone sometimes you want to set the build number to the last of the other system.

Seems like in the settings or enable location we could add a starting build number.

@bradrydzewski If you have any ideas around what's the best way to handle this, I'm down to take a stab at it.

[bradrydzewski]

You can do update repos set repo_counter = ? where repo_id = ?. You could use a sql script to set the counter in batch for all repositories. Example script:

cat <<EOF > setup.sql

update repos set repo_counter = ? where repo_full_name = ?;
update repos set repo_counter = ? where repo_full_name = ?;
update repos set repo_counter = ? where repo_full_name = ?;
update repos set repo_counter = ? where repo_full_name = ?;

EOF

Example command to load the script (sqlite):

> sqlite3 /path/to/drone.sql
> sqlite> .read setup.sql

[josmo]

ah yeah totally works. I was more meaning getting a UI component for folks to use and be able to set the next build counter :)

[bradrydzewski]

I would suggest we add this to the drone repo update CLI command. These sort of features get incubated in the CLI (see drone repo repair and drone repo chown) before we consider adding them to the user interface.

Setting the next build number definitely has some risks, so I think we should probably provide a warning message that we force the user to acknowledge:

$ drone repo update foo/bar --build-counter=25
Setting the build counter is an unsafe operation that could put your
repository in an inconsistent state. Please use --unsafe to proceed

$ drone repo update foo/bar --build-counter=25 --unsafe

We may also want to consider, at least initially, restricting the ability to set this field to system administrators (similar to what we do for timeout and trusted). I am flexible on this, though. If we do not put such a limitation in place, we should at least test the failure scenarios and document what happens when the value is incorrectly set (for example, to a build number that already exists, to the max int, etc).

[tonglil]

I think the UI component could only increment after a build has started right? Because the next build has to increment the build counter. If you change it to anything less, what implication does that have on the build that just ran?

[josmo]

@tonglil right now the only way to do it is once the PRs are merged and via the command line. The idea is that the admin should make sure manually to only update to a higher number since there's no verification in the code. Hence why you need the unsafe flag that Brad mentioned should be there :) This honestly solves most problems I've seen but we could open a new feature request once it's all merged in if it makes sense to be in the UI

[josmo]

It's now been merged for the CLI/Drone/Drone-go repos