Is it possible to add the --debug arg to be passed to semantic-release? #24
Labels
Comments
|
I think we could add standard debugging mechanics. |
|
What about the hanging behaviour? could it be related to |
|
Here's a good example . As you can see the first command completes successfully in 6 seconds. I then instantly run the command again and it hangs for around 3 mins before I interrupt the command. |
|
@musaabal-okaidi It's very interesting what happens here: // Verify config
await verify(context);
options.repositoryUrl = await getGitAuthUrl({...context, branch: {name: ciBranch}});
context.branches = await getBranches(options.repositoryUrl, ciBranch, context);
context.branch = context.branches.find(({name}) => name === ciBranch); |
|
First attempt straight after I read your comment worked. Then the next attempt hung, but it seems like it went a bit further. See the output below. |
|
Nothing comes to mind. Perhaps the problem relates shared streams and process spawns. We'll experiment with that anyway. |
antongolub
added a commit
to qiwi/multi-semantic-release
that referenced
this issue
Jul 19, 2020
…alization collisions relates dhoulb/multi-semantic-release#24
|
@musaabal-okaidi I've added |
|
Thanks. I'll give it a go tomorrow morning. |
|
Hi @antongolub Still the same. it works sometimes and sometimes it fails. Although the node version might be of more importance, I did also try running the tool from a Windows machine just in case the Mac was causing any issue, but I still got the same behaviour. See the output below. It contains additional stacktrace that gets printed it when I kill the process with CTRL+C. I didn't include this last week. |
|
@musaabal-okaidi |
|
Sorry I didn't realise it was a cmdline arg/flag. I thought you where referring to something within your code. Anyway, I've tried it again, but it's still the same. The command took 11 mins, then it exited on its own. I've also tried running Another example |
Hmm... semantic-release\index.js:57:22 context.branches = await getBranches(options.repositoryUrl, ciBranch, context);semantic-release\lib\git.js:66:11 return (await execa('git', ['ls-remote', '--heads', repositoryUrl], execaOptions)).stdout
.split('\n')
.filter(Boolean)
.map((branch) => branch.match(/^.+refs\/heads\/(?<branch>.+)$/)[1]); |
|
Certainly looks like it, but as soon as I kill the process and immediately start it again it works so it doesn't really make sense. My network settings, connections and configurations do not change at all between the each command execution. Either way I guess there's not much you could do as it's an issue isn't with the calls that I'll raise it on the |
|
Crazy, but it might work: switch protocol in repo urls in all |
|
That didn't work. However; it definitely seems to be an issue with throttling as In a real life scenario, it will not ran that often so we should probably never see the issue, but while testing, it's a bit annoying to have that restriction. I found this which could be useful if anyone is running a private git server. Also, I'm testing |
|
@musaabal-okaidi bash-glob requires bash 4.3 or later |
|
ah makes sense. It worked on a Windows machine that had git bash installed. However; I don't think the CI server has Git bash installed and I don't have admin access. I'll ask the admins to install git bash then I'll give it another bash (bash in informal British is a "try" or "attempt")😄 |
Thanks. Installing bash made it work. |
This also worked. I wasn't thinking straight yesterday I made the change in the |
|
Nice. Don't close the ticket, I'll add a debugger anyway. |
|
Sure, I'll leave that to you. btw, It's not important, but it would be nice if the sequential run was for the whole process and not just the init. The reason I say that is because I think the output would be much more readable if you could see the steps for each package listed together especially if parallel running isn't really a concern which is the case for me. If that's something you see value in doing then great. If not, then not to worry as it's not major. Either way, thank you very much for your help on this. |
This can be implemented, but as a result, we will lose cross-package dependency updates. msr automatically creates these patches. If your monorepository packages are independent (which is a bit weird), you can use pmowrer/semantic-release-monorepo and run releases as a single queue through lerna. |
|
Thanks. I think I tried The packages are IaC configurations so they don't necessarily have any dependancies between them. |
antongolub
added a commit
to qiwi/multi-semantic-release
that referenced
this issue
Jul 21, 2020
|
🎉 This issue has been resolved in version 2.3.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The
semantic-releasecommand has a--debugarg that can be passed to it. Is there any way to have debug output frommsrorsemantic-release?I'm noticing strange behaviour from
msrwhere it just hangs forever, but randomly works as well. So I'm trying to find out what the issue is.The text was updated successfully, but these errors were encountered: