I have used a package github/amar/logger (for example only) in my local unix system and now i am moving my application to production server. But package has been removed from that github repo.
So what will happen in that case ?
As long as you do not need to rebuild, nothing will happen. Though if you have to rebuild, you’ll not be able to, unless you still have a copy of that repo which you can then “vendor” with your source code.
So what if a i say i am working on a application for last 6 months and when i move to production and create cl/cd for the same and package is deleted. then what should i do ?
I know i can build app from my local.
Hi @Amardeep_Saini,
If the repository is a Go module, it will remain available through the Go team’s Go proxy server (or any other Go proxy server if your Go env is configured to use a different one).
The only requirement is that the module (or more precisely, a particular version of a module) has been downloaded once (no matter by whom). From that point on, the proxy server keeps the module cached.
The Go proxy server is hence an effective defense against a “left-pad”-like incident.
2 Likes
Hi @christophberger, Thanks for you reply.
This is the exact response i was looking for. Really appreciate your help.
But,
proxy.golang.org does not save all modules forever. There are a number of reasons for this, but one reason is if proxy.golang.org is not able to detect a suitable license. In this case, only a temporarily cached copy of the module will be made available, and may become unavailable if it is removed from the original source and becomes outdated.
Good point.
But in this case I’d say the real problem is that the module has no license. I would not want to use a third-party module in production if the licensing is not clarified. The proxy problem is then only secondary.
There are two possible options to address this situation.
-
Host your own Go proxy. This is possible because the Go environment variable GOPROXY can be set to an arbitrary proxy URL and Go proxies for self-hosting are available or can be written with little effort. (See, for example, goproxyio/goproxy or gomods/athens, among others.)
-
Use vendoring. Granted, the Go proxy should make vendoring unnecessary, but if the proxy does not meet your needs, vendoring might be a practicable alternative.
And besides all this, all modules in use are also cached locally, under $(go env GOPATH). So in the (unlikely) case that someone pulls a module from GitHub and you happen to need that module, you still have all the files in the local module cache. If nothing else works, you could grab the files from there and move them to where the production CI/CD pipeline can find them.
Just wanted to note, if the repo had forks, and the forks are decent alternatives, you could use one of the forks as replacement? Also, if the repo is important enough for you, you could fork yourself to have a copy as backup in case needed (aside from a local copy, a forked copy on the web/github).
1 Like
Deleting your repository or changing its visibility affects that repository’s forks.
That’s a good point, this would be if you knew the forks beforehand or found them by searching online outside github.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.