Add GitHub Actions for CI

[golang-jwt]

Add GitHub Actions for CI

[mfridman]

Probably latest of major versions 1.14, 1.15 and 1.16 to follow the Go release cycle .

[oxisto]

but I also understand that having a CI train of 6 (+1) stages just for the golang versions may be counterproductive for testing and induce flakiness

In most cases yes, but since this library has 0 external dependencies and it takes about 14 seconds per Go version (see https://github.com/oxisto/jwt/runs/2647110581), I think we could afford a matrix build of those "older" versions (maybe slowly phasing them out) and them moving along the Go release cycle with current + latest 2.

[lggomez]

but I also understand that having a CI train of 6 (+1) stages just for the golang versions may be counterproductive for testing and induce flakiness

In most cases yes, but since this library has 0 external dependencies and it takes about 14 seconds per Go version (see https://github.com/oxisto/jwt/runs/2647110581), I think we could afford a matrix build of those "older" versions (maybe slowly phasing them out) and them moving along the Go release cycle with current + latest 2.

It's completely reasonable, I like this as a roadmap

[mfridman]

Also +1 for enforcing squashed merged commits. If it's not already enabled on the repo, I'll make this the default.

[oxisto]

Not having a go.mod file in the old repo as a reference... which versions do we want to test against?

• 1.16 obviously
• It seems the old travis was testing against 1.11, 1.12 and 1.13

[lggomez]

Probably latest of major versions 1.14, 1.15 and 1.16 to follow the Go release cycle .

These should be a must since the ideal scenario is to test and validate regressions compatibility against the new and LTE maintained versions (which AFAIK are the current and its 2 previous versions)

* It seems the old travis was testing against 1.11, 1.12 and 1.13

These are the old but current use cases for several users so I guess that decision is up to us. I'm a bit torn on this, the newest 3 versions (and tip as an optional) seems to be the standard for most the big repos I've seen like delve and cobra but compatibility for older versions is something not to be underestimated. I can remember at least 10 projects from my last job that were on 1.12 and were about to debate on whether to upgrade to 1.13 or not... but I also understand that having a CI train of 6 (+1) stages just for the golang versions may be counterproductive for testing and induce flakiness

[lggomez]

A contributor just added this this PR which does the initial module renaming and while it does not migrate to github actions it updates the travis file with the latest go versions. I asked permission to activate travis on this repo (I guess it went to the creator of this org @mfridman) so we can have it as a temporal CI in the meanwhile, should any unrelated PRs come and follow on with the github actions migration

[oxisto]

A contributor just added this this PR which does the initial module renaming and while it does not migrate to github actions it updates the travis file with the latest go versions. I asked permission to activate travis on this repo (I guess it went to the creator of this org @mfridman) so we can have it as a temporal CI in the meanwhile, should any unrelated PRs come and follow on with the github actions migration

Additionally, we also might decide upon a merging scheme. Looks like the original author did merge commits. I personally am a big fan of squashed merges, because it is just easier to see the actual changes. It's probably personal preference but I guess it should at least be consistent for the new commits.

[lggomez]

A contributor just added this this PR which does the initial module renaming and while it does not migrate to github actions it updates the travis file with the latest go versions. I asked permission to activate travis on this repo (I guess it went to the creator of this org @mfridman) so we can have it as a temporal CI in the meanwhile, should any unrelated PRs come and follow on with the github actions migration

Additionally, we also might decide upon a merging scheme. Looks like the original author did merge commits. I personally am a big fan of squashed merges, because it is just easier to see the actual changes. It's probably personal preference but I guess it should at least be consistent for the new commits.

+1, It's the best github has to offer in this regard and we don't have to bother people with doing interactive rebases 💦