Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support archives specified with basename param where files are in top level #36

Open
jfkw opened this issue Sep 20, 2023 · 6 comments
Open

Comments

@jfkw
Copy link
Collaborator

jfkw commented Sep 20, 2023

When the basename option is specified with an empty value it is ignored and the default autodetection mechanism is used to look for a tarball. This issue is created to discuss the proposed change in PR #35.

This case happens when the application archive does not contain a basename at all. I.e., there isn't any folder in its root containing the rest of files:

$ mkdir testfolder
$ tar xz test.tgz -C testfolder
$ ls testfolder
file1
file2

The PR also identifies a couple of typos in related log lines:

INFO:obs-service-go_modules:Detected basename /path/to/archive.tgz form archive name
ERROR:obs-service-go_modules:Invalid path: {ret} not subdir of {basedir}
@jfkw
Copy link
Collaborator Author

jfkw commented Sep 20, 2023

Thanks @marcosbc for surfacing this issue. We will address this by proper handling of archives in the layout you describe, or with a better error message for an empty basename argument.

If the user needs to rely on an basename argument specified but empty to control behaviour, that would be a misfeature we should address in some way that is more clear and the user intent explicit.

Can you help me understand the issue better by describing the file name and layout location of a tarball containing Go code that you are trying to solve? Please include the location of go.mod.

@marcosbc
Copy link

marcosbc commented Sep 20, 2023

You can find a couple of examples here with the Ingress Controller and Dashboard components. In the first case, the go.mod is in the archive root and in the second case, in the api subfolder (but there are more files/folders in the archive root).

Please also note that, in both cases, it is discouraged to download the source code from GitHub since they consider it a non-official release site (example), so the only official tarballs are the ones provided in the download site.

@SchoolGuy
Copy link

Another example of this would be https://github.com/openSUSE-zh/node-semver. I think it is quite common to have your go.mod in the repository/archive root.

@SchoolGuy
Copy link

SchoolGuy commented Nov 23, 2023

We could use default=argparse.SUPPRESS for the argument and use hasattr to check if the flag is given or not. That should do the trick in case we want to separate between empty and not given: https://stackoverflow.com/a/30491369

Edit: Writing this because this way we could stay backwards compatible.

@marcosbc
Copy link

marcosbc commented Nov 23, 2023

@SchoolGuy The issue mainly comes when the compressed archive does not include a basename. In the case of the application you mention, even though the go.mod is in the repository root, when you download the archive from GitHub, it will be inside the node-semver-master folder:

$ curl -sL https://github.com/openSUSE-zh/node-semver/archive/refs/heads/master.tar.gz | tar tz | grep go.mod
node-semver-master/go.mod

However, there are other cases where this does not happen:

$ curl -s https://archive.apache.org/dist/apisix/ingress-controller/1.6.0/apache-apisix-ingress-controller-1.6.0-src.tgz | tar tz | grep go.mod
./go.mod

And those cases are the ones that do not work using go_modules.

@SchoolGuy
Copy link

@marcosbc Ah it seems after your hint I was able to get my _service file fixed. Sorry for the noise then.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants