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
>
>
>
