Skip to content

Fix rockspec and version injection #53

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

Merged
merged 4 commits into from
Apr 8, 2022

Conversation

Totktonada
Copy link
Member

This patchset should actually finish the implementatoin of the graphql.VERSION string generation.

Follows up #29.

There are two reasons:

* The module is written purely in Lua (without Lua/C parts) and nothing
  blocks us from deliver .all.rock. There is no much difference for this
  module, but .src.rock is usually something to compile before
  installation. See [1] for details.
* We can't write a version into the `graphql/init.lua` file for
  .src.rock.

Steps to illustrate what does not work with .src.rock:

* Step into the git repository.
* Rewrite `graphql/init.lua`.
* `tarantoolctl rocks new_version --tag $TAG`
  - Creates a rockspec with `source.tag = $TAG`.
* `tarantoolctl rocks pack graphql-$TAG-1.rockspec`
  - Downloads a fresh (unmodified) source from the git tag.
  - Packs the unmodified sources into .src.rock.

The steps differ, when we're pack into .all.rock:

* <...>
* `tarantoolctl rocks make graphql-$TAG-1.rockspec`
  - Installs the modified content of the git repository into `.rocks`.
* `tarantoolctl rocks pack graphql $TAG`
  - Packs the modified content from `.rocks` into .all.rock.

[1]: https://github.com/luarocks/luarocks/wiki/Types-of-rocks

Follows up #29
I guess it should ease scripting around the version string.

Also changed `'scm-1'` to `'unknown'`, because we actually don't know a
way how the module is installed: loaded from a local git clone,
extracted from a release .zip archive generated by GitHub or actually
installed from the scm-1 rockspec. In all those variants
`graphql.VERSION` will return the same predefined string.

Modified the test to make it independent of a module installation
variant. I don't meet any real problem here, it just looks more durable.

Follows up #29
Before this change I had to manually upload a new scm-1 rockpec to the
rocks server after pushing an update to the git repository. Now it is
automated.

Follows up #29
@Totktonada
Copy link
Member Author

There are several alternatives:

  • Use build.type = 'cmake' in the rockspec and call git describe from cmake by @no1seman. See Use cmake build instead builtin #50.
  • Use build.type = 'make' in the rockspec and call git describe from make (my PoC). See 332b1ab.
  • Continue to generate the version file from CI. This patchset.

The unobvious thing about first two options is that they only work while tarantoolctl rocks make/pack is invoked from inside the git repository (see #50 (comment)). Burrying it down to the tarantoolctl rocks make/pack level just hides what is actually going on.

So I prefer the simple and explicit variant and propose it here.

@Totktonada Totktonada merged commit 58b64a6 into master Apr 8, 2022
@Totktonada Totktonada deleted the Totktonada/gh-29-fix-version-injection branch April 8, 2022 23:12
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

Successfully merging this pull request may close these issues.

1 participant