Fix for go tools called from make #568
Labels
No Label
kind/breaking
kind/bug
kind/build
kind/dependency
kind/deployment
kind/docs
kind
enhancement
kind
feature
kind/proposal
kind
question
kind
refactor
kind/security
kind/testing
kind/translation
priority/critical
priority/high
priority/low
priority/medium
reviewed/duplicate
reviewed/invalid
reviewed/wontfix
skip-changelog
status/blocked
status/has-backport
status/has-pull
status/needs-backport
status/needs-feedback
status/needs-reviews
status/wip
upstream/gitea
upstream/sdk
No Milestone
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: gitea/tea#568
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch ":toolsfix"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Fixes #567 by offloading the
$PATH
interpolation to the shell instead of letting make handle it.Tested and works on Linux, tested and works on Windows using MSYS2/MingW64. Not tested on a pure Windows env without translation layers, but nothing was changed that would actively break it either.
RE: #567 (comment)
@jolheiser the makefile for gitea works, but it would imply forcing updates of the selected tool versions whenever available. If that's desirable, I'll commit that instead and see if removing the
$PATH
change altogether works while I'm at it since it makes the entire line redundantThe referenced makefile runs the tools at those exact versions, which theoretically means it should be more consistent than it currently is because
Unless I'm misunderstanding what you said.
I'm not too familiar with the Go toolchain, and I'd expect
go run x@latest
to always download and run the latest version available upstream for a package. Even if any locally available version satisfies that dependency, I'd expect it to still have that effect on CI runners that start in a clean env on every build.Please do tell me if I'm wrong. I'll see if I have the time to edit and run the proposed changes later today or somewhere this evening on a clean env
You're correct, which is why the referenced Makefile in the main repo pins the version, so that everyone runs the same pinned version rather than
@latest
2e99a21c05
to299be090a0
Sorry for letting this sit for a while. Had a little while off and forgot some things at the office.
Tested this to work on my local env, on a clean env and it passes the CI runs. Unless there are any concerns, this looks fine to me