Add fossil resolver #530
Add fossil resolver #530
Conversation
…ds into add-fossil-resolver
* Use "trunk", not "tip" * We don't need to actually open the Fossil repos in the cache once they're downloaded.
|
Is there any chance this will be included in the next shards version? |
This is necessary for projects that are themselves under Fossil.
|
I had a look at the circleci tests and they are failing because the USER environment variable is not set. There is a list of builtin variables here https://circleci.com/docs/2.0/env-vars/#built-in-environment-variables |
|
Thank you! I've implemented that change and we'll see if it works. CI stuff is still very foreign to me. |
…r argument for open.
Versions before 2.12 did not have a --workdir argument for the timeline command, and were more strict about argument ordering. This can be faked using Dir#cd and arguments in the correct order. Versions before 2.14 did not support the --format/-F argument for the timeline command. As a workaround, we can use timeline + whatis to get the full artifact hash.
| end | ||
|
|
||
| retLines.reject! &.nil? | ||
| [/artifact:\s+(.+)/.match(run("fossil whatis #{retLines[0]}")).not_nil!.[1]] |
There was a problem hiding this comment.
This looks like it returns a list with only a single commit instead of a list of all commits. What's the reason for that?
There was a problem hiding this comment.
That mirrors the behavior of the Mercurial code, which this was based on. That code looks like this:
run("hg log --template=#{Process.quote("{node}\n")} -r #{Process.quote(rev)}").strip.split('\n')Let me go ahead and adjust the Fossil-based stuff to not rely on a list since it seems like it's not needed.
|
The code quality is really great, thank you! In particular, the workarounds for older fossil versions are great. However, I'm wondering a bit whether they are actually necessary. Workarounds add complexity to our code. I don't have any fossil usage experience. So I really can't tell if it would be too restrictive. But considering some of the more recent enhancements seem to be pretty useful, I would expect fossil users to probably be tracking recent releases more closely? |
The version in various package repositories can be quite old, but considering how easy it is to install by just downloading and placing the binary in /usr/local/bin/ I don't think it would be unreasonable to require a newer version. |
Co-authored-by: Johannes Müller <straightshoota@gmail.com>
Co-authored-by: Johannes Müller <straightshoota@gmail.com>
I kind of expect the same thing, but I also can see situations where an end user who's also a power user who just wants to do a The workarounds I put in were only the bare minimums to support feature parity with Git and Mercurial with some of the more obscure (to me, anyway) ways that Git and Mercurial are used by Shards behind the scenes. But if you feel they should be removed, I'd be more than happy to remove them ^_^ |
|
I suppose it's probably best then to leave those workarounds in for now. You already invested to implement them, so it seems bad to just throw it out and exclude users of older versions. We can always do that once maintainting the workarounds becomes a nuisance. |
This PR implements a resolver for Fossil repositories. The implementation is based mostly on the Git resolver, with some parts based on the Mercurial resolver, then tweaked to match the behavior of Fossil. The tests are based on the Mercurial tests since Fossil supports named branches.
I'm somewhat unsure of my changes to the
.github/workflows/ci.yamland.circleci/config.yamlsince I've never used these features before, but I believe they're correct.FWIW,
make testran to completion on my local machine, and I also did a quick test with a Fossil repo I already had set up.This is to close #529