Accept 0.8 tokens

[bradrydzewski]

See if we can accept 0.8 tokens with 1.0 to simplify the transition for teams that are upgrading

[bradrydzewski]

@jimsheldon I am brainstorming a fix for this. I was thinking maybe we find / replace secrets in the database to update tokens automatically. This would ensure pipelines using drone tokens would continue to work in 1.0 without modification. This would not solve the broader compatibility issue, for example, people using their tokens with drone-cli would still need to update. Wondering if this would be an acceptable compromise or not?

Do you know how many repositories this impacts? And do you know if projects using Drone tokens follow some sort of naming convention (e.g. drone_token)? Thoughts on proposed solution?

[jimsheldon]

I think drone tokens are used very little in drone pipelines, they are more used by external processes like kubernetes cron jobs (I think some teams even trigger jobs in drone from TravisCI and CircleCI).

If the tokens can't come over from 0.8 as-is, I think we would be ok with that. We would just have to communicate this to our users ahead of time.

[bradrydzewski]

thanks for the reply. I have some other approaches that I can consider

[bradrydzewski]

as a workaround to simplify migration, it is possible to provide drone 1.0 with a file that maps legacy secrets to users. This allows the system to accept 0.8 tokens. The file format is the following:

{
  "octocat": "cCI6IkpXVCJ...",
  "spaceghost": "NiIsInR5cC..."
}

The file path is passed to the drone server using the DRONE_LEGACY_TOKEN_MAPPING_FILE environment variable. For example:

docker run \
 --volume=/etc/drone/mapping.json:/etc/drone/mapping.json \
 --env=DRONE_LEGACY_TOKEN_MAPPING_FILE=/etc/drone/mapping.json \

I will update the migration utility to generate the mapping file automatically.

[bradrydzewski]

this is merged in master and will be part of a 1.2.1 release that I plan to cut tomorrow, along with a few other fixes related to yaml migration.