Get rid of URL triggers

[fasterthanlime]

It's possible to do everything with SCM-poll

[fasterthanlime]

So here's what I found:

• A) With pollscm, no schedule, and a hook like https://ci.itch.ovh/git/notifyCommit?url=https://github.com/itchio/butler, the Git plug-in will never build the same commit twice.
• B) When a build is parameterized with something like JENKINS_TAG, and the git branches are set to $JENKINS_TAG, the scmpoll trigger on the "main" job will never trigger because no branch ever matches unexpanded $JENKINS_TAG (and, no, having a default value doesn't matter either)
• C) Triggering a downstream build always builds even if there's no new revision to build (that's the only way you can rebuild a revision afaict)

I've been trying forever to make a 2-job setup work, but we actually need two trigger jobs, one that builds all commits once (branches: **), and one that builds all tags once (branches: origin/tags/* in conjunction with refspec: '+refs/heads/*:refs/remotes/origin/* +refs/tags/*:refs/remotes/origin/tags/*' — checks out all the tags as branches), and they both trigger the main job, which has two parameters:

• JENKINS_TAG, used in git scm branches so it builds the right revision
  • equal to ** for "build every commit"
  • equal to vX.Y.Z for "build tags"
• JENKINS_DEPLOY
  • equal to 0 for "build every commit"
  • equal to 1 for "build tags"

That way, the git plug-in makes sure every commit is built once on its own and every tag is built once. If a build fails and you want to retrigger it (for example random disk corruption on a windows node) you can simply manually build the relevant trigger.

And you can always force a build/deploy by building the main job manually.

Other random stuff I've learned:

• Stuff like GIT_REVISION is a Jenkins macro token (or whatever they call it), not actually part of the environment for shell scripts, except if you use the EnvInject wrapper (wrappers: - inject in cigale)
• Don't bother computing triplets to get both 32 & 64-bit win binaries, just put /mingw32/bin or /mingw64/bin on the front of $PATH, it's easier
• Don't bother writing both shell & batch, just run windows nodes from mingw-w64 and have everything as shell steps.
• Don't bother writing groovy at all and just write everything as one big shell script
  • On that note, Groovy scripts either completely working or completely failing with a null error is bullshit of incredible proportions
• Ubuntu is stubborn and dash is the worst so refrain from using [[ and use [ and quote everything and beware every edge case. There's probably tools to make sure a script is POSIX-compliant or some shit (like Ubuntu's checkbashisms or whatever)
• Don't bother messing with workspace/child-workspace for go projects, just use jenkins' git plugin "check out in a subdirectory" option instead.
• My 1TB HDD is probably about to break down 🙈