Untitled :: Plugin Installer Documentation

indexmenu_n>27

CI: Push build to Git Release

Initiate the push with 'git push origin [tag]'

In both .travis and appveyor it is possible to initiate the push of a build to your Git repository. These instructions assume that you appveyor and travis accounts and know your way around their services and basic process. Your travis account is used to confirm 'successful' builds of linux and osx, and to create those packages and releases.

How to push a .Travis 'built' file to a new Github 'Release'

For travis refer to Petri’s post #637

A. Configure CMake and the Travis file for security and permissions

You can use this Dashboard-Tactics_pi .travis file as it is. The MacOSX section packages a fully automated installation (FAI). The two build target conditional variables are courtesy from Sean d’Epagnier’s repositories.
Also changes in Cmake include files are needed for Mac Packaging, in particular PluginPackage.cmake note the MacOSX entries. Also see this post and necessary changes by Nereus32 (There may be some other changes to cmake needed..Petri?)+'- SET(TACTICS_INSTRUMENTS ON)' IF (TACTICS_INSTRUMENTS) PROJECT(dashboard_tactics_pi) SET(PACKAGE_NAME dashboard_tactics_pi) SET(VERBOSE_NAME DashboardTactics) SET(TITLE_NAME DashboardTactics) ELSE (TACTICS_INSTRUMENTS) PROJECT(dashboard_pi) SET(PACKAGE_NAME dashboard_pi) SET(VERBOSE_NAME Dashboard) SET(TITLE_NAME Dashboard) ENDIF (TACTICS_INSTRUMENTS) +

Plus, take the dashboard_tactics_pi.pkgproj.in where I modified the key NAME as instructed.
Repeat the build process from zero on an empty build directory and let me know.

B. Bottom of travis.yml file

Example Bottom section of the travis.yml file. Note: indentation is important in yml files, child parts MUST be indeted below the owner. This is shown below by "api_key:" being the owner and "secure:" being the child, noticd that "secure:" is indented.

deploy:
- provider: releases
  api_key:
    secure: "Your encrypted github token here"
  file_glob: true
  file: "$TRAVIS_BUILD_DIR/build/*.{deb,rpm,dmg,txz,pkg,pkg.tar.xz}"
  skip_cleanup: true
  on:
    repo: canne/dashboard_tactics_pi
    tags: true
    all_branches: true

If you want another deploy section, like launchpad, you will need to create a new "- provider:" with the text "launchpad" following it. Both "- provider:" labels need to have the same indentation.

C. Install Travis CLI to encrypt a Github secure public key

You need a travis CLI (command line interface) to be able to encrypt the GitHub token. The encrypted string is put in your personal .travis.yml file. Unlike AppVeyor services, there is no on-line encryption service, that’s why you need to start with a travis CLI installation

 - [[https://github.com/travis-ci/travis.rb|Travis CLI Tool]] for Windows Developers use [[opencpn:developer_manual:ci_travis_encryption_windows|Rubyinstaller/Gem/Travis]] which still uses 1Gb of disk space but is the easiest alternative.
- Travis CLI installation instructions for Windows (Suggest use of "Travis CLI Tool" above). When you are sure that you have travis CLI up and working, you can start to create the encrypted key. Without it, deployment to GitHub does not work.
- Travis CLI installation instructions for Linux are just below. Note that Windows10 users can:
   * Install a Travis CLI Tool as listed above (easiest).
   * Create a [[https://opencpn.org/wiki/dokuwiki/doku.php?id=opencpn:supplementary_software:run-ubuntu-in-win10|WSL-Windows Subsystem for Linux (Ubuntu 18.04LTS) on Win10 Installation]].
   * or create a Virtual Box and install Ubuntu Linux.

and then from the linux command prompt execute:`+ sudo apt-get update --fix-missing sudo apt-get install ruby sudo apt-get install gem ruby -v gem install travis -v 1.8.10 --no-rdoc --no-ri travis version response: 1.8.10.

225mb disk space used. +`

D. Encrypt a Github API Token with Travis encrytion

Create a Github API token for travis in GitHub here Developer tools. Select all rights to repository "repo" and repository only (that’s enough - if it does not work, it is something else). Don’t close the window until you have made a copy of your key.
Open command window and give following command (in Linux) with travis CLI:`+ echo [Paste GitHub Token Here] | travis encrypt -r [username]/[repository_name] --org +`

E. Copy and Paste the encrypted key into the Travis secure field

The command above produces a very long arbitrary string in format "1234abcde….f".
Copy and paste that into .travis.yml in secure field as one single line. Don’t let your editor to break it on different lines.
Warning: Beware the interweb instructions, which are supposed to modify the .travis.yml on the fly…they mes up the file completely the file. So stick to copy-paste.
Save the Travis file.

F. Start building the .travis project

You will need to turn the project "on" after signing into your travis account. Click on the icon in the top right with the down chevron and select 'Settings', the page will display your respitories under the 'Repositories' tab. Make sure the ones you want to use have the slider button to the right with a tick in the button. If it is to the left and shows a cross it is not active.
Remember to change VERSION.cmake patch number and date, an commit and push that too! This is important if you are going to create a release as this will help identify the build objects belonging to the release.
Then when you commit and push the .travis.yml file, the travis build will start. It is good to check that both of its build processes do pass faultlessly before the next step.
It takes awhile for each commit (Linux and Mac) to build correctly, be patient when it is running.
Make sure it built successfully. The project will not be saved because travis does not provide that type of storage space.

G. Deploy 'build' to Github

Now the project is ready to create a Release in Github. There are two ways to do this.
Option 1: Create the new 'Tag' from within Github Release Tab.

    * In GitHub create a repository, like v1.2.3 as 'tag', description can be anything, but it best to include the version. This is where Travis and AppVeyor both deploy the built contents.
    * When you hit the create button, Travis and AppVeyor will create the 'build' and deploy (the condition flags in the configuration file are define this action) to the Github 'Release' Tag.
    * That's why it's important to check before you create the 'Tag' that all builds do pass faultlessly. (Repositories cannot be deleted since they are, in fact defined by tags.)
    * If you observe 401 error at the deployment phase in travis logs search in google.com with the following phrase for possible causes "travis github [[https://api.github.com/user|https://api.github.com/user]]: 401 - bad credentials"
- Option 2: Command Line - Make a 'Tag' locally and push it to your remote.
    * From your command line create a new tag locally, and then push that tag to your remote repository.
    * All the same cautions apply, make sure it builds properly first.<code>

OPTION 2: TAG COMMANDS Make tag locally and push to remote git tag v1.13.1 ←-Create the tag on your local repository git push origin v1.13.1 ←-Push the tag to your remote repository, travis creates build and pushes. git push –delete origin v1.13.1 ←-You’ve made a mistake, it fails to build, remove remote tag. git tag –delete v1.13.1 ←-You’ve made a mistake, it fails to build, remove local tag. Fix the problem and start over. </code>

==== H. Troubleshooting

When the Travis build does not work the error messages can be obscure and not really help too much. A typical message may be:

Skipping a deployment with the provider because this branch is not permitted:

This is not very helpful as it just says something went wrong not what.

Check your whole .travis.yml file. Look at it carefully and compare it to the example given.
Make sure you have the security token enclosed in double quotes, i.e. "security/token"
Make sure the build process has actually worked for the file types you are trying to transfer to github
If you have extra values in your yml file make sure you really know what they do. If you have issues, take all the extranous values out and see if it works then.
If necessary find a very small project and play with that as it will compile much quicker.
Make all changes in a branch of the main repository as you will have to do multiple commits to get it working. Once it is working you can make the changes to your main branch(es) and clean up the 'test' branch

=== How to push an Appveyor 'built' file to a new Github 'Release'

The use and configuration of Appveyor is similar to Travis in many respects. We use Appveyor to create Windows packages.

==== A. Configure Appveyor.yml file for security and permissions

# Artifacts Configuration
artifacts: # push all files in directory
  path: build\*.exe
  name: installer

# Deploy to GitHub Releases
deploy:
# description: 'release created by AppVeyor CI'
  provider: GitHub
  auth_token: # '%GitHub_auth_token%'
    secure: VVAVg9a...[put the appveyor encryption of your github public token here ]...f1OSYg0tS
  artifact: installer
  draft: true
  prerelease: true
  tag: $(APPVEYOR_REPO_TAG_NAME) # use pushed Tag or insert version name
  on:
    configuration: Release  # Debug contains non-redist MS DLLs
    APPVEYOR_REPO_TAG: true   # deploy on tag push only
#   branch: master   # release from master branch only

You can also use this Weatherfax_pi appveyor.yml file for reference and there are some in process notes available.
Login to your Appveyor Account and Create a Github API Public Security Token under New Personal Token, entering a "Note" similar to Appveyor_auth_token[plugin_name]_ and then select a Permissions "Scope" for "REPO" by checking "Repo".
Copy the resulting code to your clipboard and somewhere else, as this is the last time you will have access to the public key.

==== B. Encrypt a Github secure public key using Appveyor Encrypt Service

Sign into the Appveyor Encryption Service and paste the public key into the field.
Push "Encrypt". Copy the result to clipboard.

==== C. Copy and Paste the encrypted key into the Appveyor secure field

Then paste that into the appveyor.yml file after auth_token: and secure:, where the words <encrypted GitHub API token here> occur. The encrypted public token can be enclosed by quotes.
Save the appveyor.yml file,

==== D. Start building the Appveyor project

You will need to select or turn the project "on" after signing into your appveyor account.
Then when you commit appveyor.yml file, the appveyor 'build' will start. It is good to check that its build processes do pass faultlessly before the next step. Commit and push to the remote repository.
Additionally you must remember to change VERSION.cmake patch number and date, an commit and push that!+git add appveyor.yml git commit -a -m "update appveyor.yml" git push origin master +

==== E. Deploy 'build' to Github

It takes awhile for the commit (Windows) to build correctly, be patient when it is running.
Make sure it built successfully by checking that the Artifact Tab for the install package file.
Now the project is ready to create a Release in Github. There are two ways to do this.
Option 1: Create the new 'Tag' from within Github Release Tab.

    * In GitHub create a repository, like v1.2.3 as 'tag', description can be anything, but it best to include the version. This is where Travis and AppVeyor both deploy the built contents.
    * When you hit the create button, Travis and AppVeyor will create the 'build' and deploy (the condition flags in the configuration file are define this action) to the Github 'Release' Tag.
    * That's why it's important to check before you create the 'Tag' that all builds do pass faultlessly. (Repositories cannot be deleted since they are, in fact defined by tags.)
    * If you observe 401 error at the deployment phase in travis logs search in google.com with the following phrase for possible causes "travis github [[https://api.github.com/user|https://api.github.com/user]]: 401 - bad credentials"
- Option 2: Command Line - Make a 'Tag' locally and push it to your remote.
    * From your command line create a new tag locally, and then push that tag to your remote repository.
    * All the same cautions apply, make sure it builds properly first.<code>

OPTION 2: TAG COMMANDS Make tag locally and then push to remote </code>

Examples:
git tag v1.9.1-ov42    <--Create the tag on your local repository
git push origin v1.9.1-ov42  <--Push the tag to your remote repository, travis creates build and pushes.
git push –delete origin v1.9.1-ov42  <--You've made a mistake, it fails to build, remove remote tag.
git tag –delete v1.9.1-ov42  <--You've made a mistake, it fails to build, remove local tag.
Fix the problem and start over.

==== F. What happens upon Deployment

The git push origin v1.9.1-ov42 Tag command is executed.
Upon which a new Release & Tag "v1.9.3-ov42-test" gets created in GitHub "Releases", which now contains the results of the - - Appveyor build under the "Assets" label. You should find a file similar to "weatherfax_pi-1.9.3-ov42-win32.exe".
See https:__github.com/rgleason/weatherfax_pi/releases/tag/v1.9.3-ov42-test]
- The Appveyor 'Console Tab' shows: [[https:ci.appveyor.com/project/rgleason/weatherfax-pi|https:ci.appveyor.com/project/rgleason/weatherfax-pi]]
- The Appveyor "Artifacts Tab" shows the file pushed to Github 'Release': + Collecting artifacts… Found artifact 'build\weatherfax_pi-1.9.3-ov42-win32.exe' matching 'build\*.exe' path Uploading artifacts… [1/1] build\weatherfax_pi-1.9.3-ov42-win32.exe (721,873 bytes)…100% Deploying using GitHub provider Creating "v1.9.3-ov42-test" release for repository "rgleason/weatherfax_pi" tag "v1.9.3-ov42-test" commit "05b6418e674b7d722424146c8efe2745a88b635b"…OK Uploading "weatherfax_pi-1.9.3-ov42-win32.exe" to release assets…OK Build success +
  1. How to get to these Appveyor Locations? The simplest way to access Appveyor is through Github commits eg:https://github.com/rgleason/weatherfax_pi/commits/master
    
    If appveyor succeeds in creation of an Artifact - green check.
    
    If appveyor succeeds in creation of an Artifact and a Release (if a new Tag is pushed to remote.) - green check.

Note that VERSION.cmake entries/changes and TAG must be manually coordinated!

=== Additional Notes

For more information about setting the auth_token security please read notes in Appveyor Forum discussions:

It just updates the patch number and updates the Appveyor file so that we can push a new tag to the remote repository and then appveyor will push the windows artifact into the Release (new tag). (This just requires the setup of a personnal auth_token and copying the Yaml encrypted version of that into the appveyor file.)

It’s a nice efficient way to make a release with an identical tag. This is what I’ve done on my repository:

==== More information for Appveyor