Problem with CommonMarker on an Azure VM #226
Comments
|
A few questions:
If I had to guess I’d say that the VM is lacking some necessary build packages, such as a C compiler. There should also be some output/debugging logs in a tmp folder within the Commonmarker is tested and confirmed to run on Linux, windows, and macOS, which is why I think the VM might be missing a build dependency. But without better logs it’s hard to tell what is going on! |
|
Yeah, that idea does make sense to me. The main confounding factor is, the VM in question is a transient VM used in an Azure build pipeline, so exfiltrating these details takes a bit of finagling. :-P What's really weird, though, is that if I write a Ruby script to explicitly |
|
This is from the top of the build log: |
|
The last successful build shows it downloading and installing commonmarker version 0.23.6, only one revision back from where the failures started. That seems unlikely to be the cause but can't be discounted at this point. |
|
Last successful build: |
|
@phillmv @anticomputer Could you please help investigate this? It suggests that something broke in the recent cmark changes y'all made. @logiclrd Would you be able to upgrade to commonmarker |
|
I'm wondering if its because there's confusion about the commonmarker dependency because github/jekyll-commonmark-ghpages#28 has not been merged yet. We've pretty extensively tested the build matrix across Linux, MacOS and Windows and do not expect to see build failures, is there any way we could see more verbose build/install logs? |
|
@gjtorikian Unfortunately, |
|
@logiclrd are you dependent on https://github.com/github/pages-gem per chance? I see (internally, I'm a GitHub employee) that team is still in the process of releasing a new gem that has the proper dependency chain and requirements in place to use this commonmarker version. |
|
@anticomputer I've grabbed the full build log and thrown it up here: https://distribution.iqmetrix.net/buildlog.txt It's a bit big but each build step is clearly delineated between |
|
@anticomputer Yep, that's the one, the complete Gemfile looks like: |
Is there any difference between the Ruby version for the local build that succeeds and the 3.1.3 used on the AzureVM? I'd also be curious to see the value of the RUBY_DLL_PATH on the AzureVM if at all possible. |
|
Maybe a tiny difference? Or maybe none at all. The build log says that it's locking the version to 3.1.3. Locally, I get: I don't know if the |
|
I'll add a build step to output the environment and get back to you. |
|
Interim trouble shooting summary for folks following along: The fact that LoadLibrary succeeds, commonmarker.so does build fine and does exist, yet A local Windows build of the same dependency stack on a Windows system with a similar Ruby version does succeed. Separately, as noted previously, pages-gem and jekyll-commonmark-ghpages themselves are pending an update and new release, but I don't think that would impact things much since all the involved dependencies are "~>" either way. |
|
The build is invoked using a Bash build step that invokes I don't see anything specifying a value for |
So I'd be curious what happens when you specify a RUBY_DLL_PATH for that step set to "C:/hostedtoolcache/windows/Ruby/3.1.3/x64/lib/ruby/gems/3.1.0/gems/commonmarker-0.23.7/lib/commonmarker/" or alternatively, copy commonmarker.so into "/c/hostedtoolcache/windows/Ruby/3.1.3/x64/bin" ... it'd also be useful to diff the build environments of the local build that succeeds to this one. The symptoms are that of Ruby not having a properly configured DLL search path, since the commonmark build itself succeeds fine and the artifact is a valid and loadable DLL. EDIT: during the bundle exec jekyll build that is |
|
I made a build step to check |
Could you also share the output of |
|
Piping in to add: also what about a |
|
Alright I have these additional bits of output.
|
|
I like to keep the issues in my OS projects open to let me know there’s something actionable for me to do. As this hasn’t had an update in two weeks, and it sounds like a specific issue to the server, I’m going to close it out. Feel free to keep discussing; I had thought that the time the issue was opened was related to the recent release but that doesn’t appear to be the case. |
We are encountering a problem with CommonMarker as part of a build on an Azure VM. It is an indirect reference to CommonMarker; our project uses
github-pages, which in turn usesjekyll-commonmarker-ghpages, which referencescommonmarker. When I run the build locally, it succeeds, but on the Azure VM, it gives the following error:I have investigated and found that the file at the specified path does in fact exist. In addition, I made a test script to explicitly call the Win32 LoadLibrary API function on that path, and it loads successfully. But, a
requirestatement pointed at it fails, not locally but on the Azure VM running the build pipeline. I've run out of things to check next at this time. Do you have any idea what might cause these symptoms?The text was updated successfully, but these errors were encountered: