uhh... never mind
On Wed, Nov 20, 2019 at 4:34 PM ocket 8888 <[email protected]> wrote:
> The routes don't need to be regular expressions though. That's a change
> that still needs to be made, and while it would have other benefits beyond
> this whitelist/blacklist, it is a significant amount of work that may or
> may not be more than the work of getting regular expressions to work, so
> idk if you wanna do that but it's true. Then, as far as path parameters,
> you can just strip them before comparison by doing something like
>
> regex.MustCompile(`\{[^\}]+\}`).Replace(path, "")
>
> not actually familiar with that api, but the point is that comparisons can
> be made to ignore path parameters probably pretty easily - as long as they
> are just strings.
>
> On Wed, Nov 20, 2019 at 3:17 PM Hoppal, Michael <
> [email protected]> wrote:
>
>> I am in agreeance here and +1 on Option 2.
>>
>> Not only is the version "vetted" but also keeps our Go version for
>> building consistent across services that are in the same repository which I
>> think is of value as well. I know personally when I am developing I am
>> probably not going to remember to switch my go version as I switch between
>> services.
>>
>> Michael
>>
>> On 11/20/19, 2:18 PM, "Rawlin Peters" <[email protected]> wrote:
>>
>> Hey all,
>>
>> The Go version for building Traffic Ops is currently pinned to 1.11
>> due to issues communicating with Riak when using 1.12 or 1.13. All of
>> the other Go components are currently built using the version provided
>> by the `golang` package from EPEL, which is currently 1.13.3.
>>
>> My question is: are we content keeping all non-TO Go components using
>> the version provided by EPEL, since we haven't really identified an
>> issue using 1.13 for those components (although I'm not sure they've
>> really been "vetted" by anyone yet), or do we pin them back to 1.11
>> since that is the "vetted" version?
>>
>> These are some of the options I can see:
>> 1. leave non-TO Go component builds as-is, they will use whatever
>> version is provided by EPEL (might catch us off-guard, but we'll stay
>> up to date by default)
>> 2. pin the rest of the non-TO Go components to 1.11 (since that
>> version is "vetted") then advance versions for components only after
>> thorough testing
>> 3. pin some Go components to 1.11, optimistically pin others to 1.13
>> if they're not as production critical
>>
>> Advancing components to new versions of Go seems like something that
>> should be deliberate and tested, so I'd lean towards Option 2 for the
>> time being. What option do you think is best?
>>
>> - Rawlin
>>
>>
>>
