Set(GIT_REPOSITORY_NAME "testplugin_pi") <-Set the Git Repository Name Set(GIT_USER "rgleason") <- Set your git user name #set(GIT_USER "jongough") <- Git user commented out Set(PACKAGE "testplugin") <- Set plugin name (twice) Set(TP_COMMENT " * Release for O5 using CI") Set(VERSION_MAJOR "1") <-Set your version number and comment Download and install the files into a new branch on your plugin local repository.ĬMakeLists.txt <- Your version and this version will have to be merged. will start with 'opencpn-plugin-' the the rest of the descriptive name.ĭownload and Use the CMake and CI files listed below from Jon Gough's Testplugin_pi using the “cmake_flatpak_test” branch. Master build without tag and non-master branch build with tag -> beta repositoryĪll 'installation' files, 'deb', 'dmg', 'exe', etc will also go into the same repository, but they will have the current naming strategy, i.e. Īny non-master branch network build -> alpha repository The destination repository is controlled by what you are doing, i.e. You will notice that I have changed the names of the repositories to '…-prod', '…-beta' and '…-alpha', it just seemed to match what was going into them. The idea of this process is that it is a 'black box' to most and it should 'just work'. When I make changes just copy the new files in place and, if needed, make the co-requisite changes to CMakeLists.txt. I would not try to 'combine' this process with any other in the same 'stream' or you are likely to have problems. You will also need the last section which does the rest of the build and package process. You will need to keep 'SRCS' as the source list, but the rest of it is up to you. In the current file the following section (line 194 onwards) is where you define all the files to be used. 'USE_GL', or some special version of c++ that is needed. The next section down you may need to change a few default settings, i.e. So if you look through the first section of the CMakeLists.txt you will see where you set the cloudsmith user and repository name as well as the 'special' stuff for the xml file. It should be quite easy to get it working, while testing on the web takes longer as jobs need to finish, to determine what needs fixing. Updates of plugins require copying the above directories in place and then carefully updating the CMakeLists.txt file by referencing the testplugin_pi version to change it to the new format and include all the 'standard' parts that are needed. 'mingw' directory should not require hand customisation So if you really needed a manual action to delete/copy/move many packages at once, you can do it like that. Some more information on how retention works here:Īlso, for manual actions, at the bottom of the packages list page, there's an “X Per Page” selector, where you can change the setting from 25 packages to 500. If you'd like to keep 30-days worth of absolute packages, just untick the box and we'll trim it down to 30 days after the next upload. The 33 packages count you have means you'd have to have 34 versions of a named package before it deletes them. Also, you've currently got “Group Packages By Name” enabled, which means it is is counting per package name, rather than the packages in total. Retention Policy only kicks in when a repository is uploaded, even for time-based retention. Response: This is normally a misunderstanding of how the retention functionality works. Deleting them 25 at a time is impractical. Retention policy set some time ago but these have not disappeared. Example: A repository with 4gb and about 5000 packages used for development.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |