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

Pushing easyconfigs to local git repo fails in 4.5.0 #3892

Closed
i-mtz opened this issue Nov 2, 2021 · 12 comments · Fixed by #3893 or #3899
Closed

Pushing easyconfigs to local git repo fails in 4.5.0 #3892

i-mtz opened this issue Nov 2, 2021 · 12 comments · Fixed by #3893 or #3899
Milestone

Comments

@i-mtz
Copy link

i-mtz commented Nov 2, 2021

After we upgraded our EasyBuild installation to 4.5.0 we have noticed that the feature we use to send the easyconfigs and build logs to an internal git repo is no longer working. We have an ssh-key for our build user that works if we do a build with a previous EasyBuild version (4.4.2 for example) but no longer works on 4.5.0. At the end of the build we get:

/scicore/home/scicore/easybuil@bc2-gl.bc2.unibas.ch's password:

There seems to be some change in the way the repositorypath configuration option is processed, which in our config is:

repositorypath=git@bc2-gl.bc2.unibas.ch:easybuild/installed_easyconfigs_tests.git

@pescobar mentioned that this commit might be related 3252979

@boegel boegel added this to the next release (4.5.1?) milestone Nov 7, 2021
@boegel
Copy link
Member

boegel commented Nov 7, 2021

@i-mtz It looks like we're not taking into account that the repositorypath value may be something totally different than a simple path value...

Can you share the output of eb --show-config with both EasyBuild 4.4.2 and 4.5.0?

@boegel
Copy link
Member

boegel commented Nov 7, 2021

@i-mtz @pescobar The changes made in #3893 should fix the problem you're seeing, can you confirm?

@i-mtz
Copy link
Author

i-mtz commented Nov 8, 2021

@boegel, yes, #3893 fixes the issue for us.
Thanks!

@Micket
Copy link
Contributor

Micket commented Nov 8, 2021

Another user mentioned issues and was using
ssh://git@x.x.x.edu:2222/xxx/easybuild/slurm-cluster/deployed-recipes.git
And, surely, some might be using local git repos with other usernames. I don't think path.startswith('git@') is good enough here.

@Micket Micket reopened this Nov 8, 2021
@Micket
Copy link
Contributor

Micket commented Nov 8, 2021

One option would be to check with regexp if we have to modify that function without https://stackoverflow.com/questions/2514859/regular-expression-for-git-repository seems very robust.

@boegel
Copy link
Member

boegel commented Nov 10, 2021

How about just checking with [a-z][@:] for URL-like paths? That'll probably work just fine in practice?

@Micket
Copy link
Contributor

Micket commented Nov 10, 2021

Sure

@Micket
Copy link
Contributor

Micket commented Nov 10, 2021

Though, technically, can't you have a .ssh/config that specifies the username for you? So it's not a guarantee.

@boegel
Copy link
Member

boegel commented Nov 11, 2021

An alternative could perhaps be to check if the value corresponding with an existing absolute path, and if it doesn't, then don't try to "cast" it to an absolute path at all?

@akesandgren
Copy link
Contributor

akesandgren commented Nov 11, 2021

Isn't the problem the code in _postprocess_config (tools/options.py) where is does

        repositorypath = self.options.repositorypath
        if isinstance(repositorypath, (list, tuple)) and len(repositorypath) == 2:
            abs_path = self.get_cfg_opt_abs_path('repositorypath', repositorypath[0])
            self.options.repositorypath = (abs_path, repositorypath[1])
        else:
            path_opt_names.append('repositorypath')

that it should only do that if self.options.repository is FileRepository ? And absolutely not if it is GitRepository ?

@boegel
Copy link
Member

boegel commented Nov 11, 2021

that it should only do that if self.options.repository is FileRepository ? And absolutely not if it is GitRepository ?

No, because GitRepository can also be local (so specified as a path), doesn't have to be remote (specified as a URL of some kind)

@boegel
Copy link
Member

boegel commented Nov 11, 2021

Another way out could be to simply skip the whole make-sure-it-is-an-absolute-path business for repositorypath, since it's quite unlikely that a relative path is specified there anyway?

The changes made in #3832 were mainly to prevent silly mistakes like in #3619, but for repositorypath it's probably much less likely that it's a problem...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment