Go Buildpack ne trouve pas le module local. Qu'est-ce que je rate?

L'éditeur php Banana a rencontré un problème lors de l'utilisation de Go Buildpack : "Le module local est introuvable, qu'est-ce qui me manque ?". Go Buildpack est un outil permettant de créer et d'exécuter des applications Go sur la plateforme Cloud Foundry. Ce problème est généralement dû à des dépendances Go manquantes ou à une configuration incorrecte. La solution à ce problème consiste à vérifier les dépendances de votre projet Go et à vous assurer que les variables d'environnement telles que GOPATH et GO111MODULE sont correctement définies.

Contenu de la question

J'essaie de créer et de lancer une application go sur https://fly.io, mais lors de la construction, je ne trouve pas mes packages de test et de modèles comme celui-ci :

.
    ├── cmd
    │   ├── doc
    │   │   ├── go.mod
    │   │   └── main.go
    │   ├── git
    │   │   ├── go.mod
    │   │   └── main.go
    │   ├── imp
    │   │   ├── go.mod
    │   │   └── main.go
    │   ├── log
    │   │   ├── go.mod
    │   │   └── main.go
    │   ├── met
    │   │   ├── go.mod
    │   │   └── main.go
    │   ├── orc
    │   │   ├── go.mod
    │   │   └── main.go
    │   ├── pub
    │   │   ├── go.mod
    │   │   └── main.go
    │   ├── rep
    │   │   ├── go.mod
    │   │   └── main.go
    │   └── web
    │       ├── fly.toml
    │       ├── go.gen
    │       ├── go.mod
    │       ├── go.sum
    │       ├── handlers.go
    │       ├── handlers_test.go
    │       ├── main.go
    │       ├── main_test.go
    │       ├── router.go
    │       └── router_test.go
    ├── contributing.md
    ├── go.mod
    ├── go.work
    ├── internal
    ├── license.txt
    ├── main.go
    ├── pctl
    ├── pkg
    │   ├── **templates**
    │   │   ├── base.qtpl
    │   │   ├── base.qtpl.go
    │   │   ├── go.mod
    │   │   ├── go.sum
    │   │   ├── whoami.qtpl
    │   │   └── whoami.qtpl.go
    │   └── **test**
    │       ├── go.mod
    │       └── test.go
    └── readme.md

https://paketo.io/docs/reference/go-reference/#package-management-with-go-modules Statut :

the buildpack will vendor dependencies using go modules if the app source code contains a go.mod file. during the build phase, the go-mod-vendor buildpack(opens in a new tab) checks to see if the application requires any external modules and if it does, runs the go mod vendor command for your app. the resulting vendor directory will exist in the app’s root directory and will contain all packages required for the build.

En regardant le journal de construction, j'ai découvert que go modvendor était effectivement exécuté.

Paketo Buildpack for Go Distribution 2.2.3
Resolving Go version
Candidate version sources (in priority order):
go.mod    -> ">= 1.19"
 -> ""
Selected Go version (using go.mod): 1.19.5
Executing build process
Installing Go 1.19.5
Completed in 35.526s
Generating SBOM for /layers/paketo-buildpacks_go-dist/go
Completed in 0s
Paketo Buildpack for Go Mod Vendor 1.0.7
Checking module graph
Running 'go mod graph'
Completed in 1.166s
Executing build process
Running 'go mod vendor'
Completed in 9.851s
Generating SBOM for /workspace/go.mod
Completed in 21ms
Paketo Buildpack for Go Build 2.0.8
Executing build process
Running 'go build -o /layers/paketo-buildpacks_go-build/targets/bin -buildmode pie -trimpath .'
Failed after 611ms
failed to execute 'go build': exit status 1
handlers.go:5:2: cannot find package "." in:
/workspace/vendor/templates
main.go:8:2: cannot find package "." in:
/workspace/vendor/test
ERROR: failed to build: exit status 1
Error failed to fetch an image or build from source: executing lifecycle: failed with status code: 51

handlers.go:5:2: “模板” main.go:8:2 : "测试"

Ce que j'ai fait :

1. J'ai changé le nom du module en une URL (c'est-à-dire test -> some.com/test) et utilisé une directive de remplacement dans go.mod pour pointer vers le module.
2. J'ai lancé Go Modvendor et j'ai regardé ce qui était généré... some.com était là !
3. J'ai essayé des versions locales et distantes via le lancement d'un vol. Les deux n’entraîneront aucun fichier de ce type.

J'essaie maintenant un référentiel privé.

Solution de contournement

Ce n'est pas une excellente solution, mais il est toujours possible de modifier le fichier hosts pour que le module pointe vers le serveur de fichiers local.

# vim /etc/hosts
127.0.0.1    <module name>

Je modifierai cette réponse si je découvre si le problème vient de fly ou de buildpack. Le problème est que lorsque fly exécute go modvendor, il ne respecte pas les directives de substitution dans go.mod.

Tant que le nom du module est au format URL, le fournisseur de mod go auto-exécutable copiera tout correctement . Il n'est pas nécessaire qu'il s'agisse d'une URL valide.

Une autre solution consiste simplement à héberger le code sur une URL valide et à en finir avec lui. Il me manque probablement un drapeau, mais je ne l'ai pas encore trouvé. J'espère que toute personne rencontrant ce problème pourra trouver cette réponse utile en attendant.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!