vim / vim-appimage

AppImage for gVim
115 stars 20 forks source link

Terminal vim & reworked Build #5

Closed rakus closed 5 years ago

rakus commented 5 years ago

Rework build, support terminal Vim

Changes

Using AppImageKit V11

The script scripts/appimage.sh downloads a file name functions.sh. This script uses v6 of the AppImageKit.

Copied some lines from functions.sh to appimage.sh and changed the URLs to use AppImageKit v11 (newest release). Important new feature: ARGV0, see below.

Startup

The gvim.desktop file is changed to call a script named vim.startup.sh. This script ...

Building

  1. Travis always checks out the "master" branch of the submodule vim and pulls the newest changes.
  2. Install needed dependencies copied from .travis.yml of Vim.
  3. Script make_vim.sh is used to build Vim.
  4. The Version is determined from the last tag from Vim and the vim-appimage repo is tagged accordingly after a successful build.
  5. A minimal body text for the Github release.
  6. Removed git commit from version/file name. Looked ugly IMHO.
  7. API-Token is now held in the Travis configuration (not as encrypted key in .travis.yml)

With this setup it is possible to build the AppImage with Travis cron jobs. So it is build daily and will automatically pick up the current Vim patch level, create a tag and a GitHub release.

E.g. Release v8.1.1211 was created by a Travis cron job.

Building via make_vim.sh is useful for local builds, also scripts/appimage.sh uses a different build directory when not on Travis.

The last point (API-Token) could be reverted. This way it was easier for me to test deployment to GitHub releases.

Testing

It is possible to copy the GVim*.AppImage file to vim/src/vim and then start make test.

This is currently not part of the Travis build, but could be added if wanted.

Before Merging this PR

Cleanup .travis.yml, so deployment to GitHub is only done on master branch (just comment section on: in deploy:).

chrisbra commented 5 years ago

Thanks. that are many changes. What's the thing about $API_TOKEN? That is not defined anywhere? I don't understand that part:

Cleanup .travis.yml, so deployment to GitHub is only done on master branch (just comment section on: in deploy:).

That is already commented and your last commit does already un-comment it? So what should be done before merging this?

chrisbra commented 5 years ago

I didn't even notice, there was an open issue #4 here. Sorry for that.

rakus commented 5 years ago

Regarding API_TOKEN: Authentication is needed for the deployment to GitHub. And there are two ways to do that. Either with a secure (aka encrypted) "api-key" in .travis.yml. The other way is to add the key to the project configuration on travis as a protected environment variable.

If this merge request is approved for merging by you, I would add a last commit to:

  1. Uses the secure api-key as it was used before
  2. To only deploy if the master branch is built.

In the current state I'm able to test deployment in my forked repo on my development branch.

chrisbra commented 5 years ago

ah okay, please go ahead :)

rakus commented 5 years ago

I realized a "problem" with the PR. During travis build it updates the Vim submodule. This changes have to be committed and must be pushed back to Github. I'm investigating.

I could continue in two directions:

  1. Continue with the PR as is and add push back to GitHub
  2. Split into two PRs. One for new AppImage build (new AppImageKit & allow terminal Vim) and another for updating Vim during Travis build, commiting and push to GitHub.
chrisbra commented 5 years ago

ah okay. If possible, I would suggest to split up the PR.

rakus commented 5 years ago

Christian, I feared you would choose the second option :-). I would have done the same.

BTW: This a commit created by Travis

rakus commented 5 years ago

Closing this pull request, as it will be splitted into two separate PRs.