-
Notifications
You must be signed in to change notification settings - Fork 21
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
Typical plugin update procedure targeting master catalog #406
Comments
Where did you get point 6) from? |
Just omit it, stick to the documentation. |
For update-template script in Windows, should I use this tag and command?
|
What a PITA it doesn't like those files? |
Also, shouldn't I be changing the version number before doing ?
|
Are we now talking about update_templates or git-push? These two are not related in any way. "Confused" |
Alec, trying to use your schema for versioning here.
Then git add and commit as git commit -am "1.3.17beta"? Then
The git add and git commit -am "update-temp to sd3.02" |
Well, this seems to have gotten the update-template script working
|
Then commited the new update-templates and ran again and got a long list of changes. |
|
Next I need to build it locally and test. |
|
I will have to fork your directory to find out what's going on. Where is it? Please don't submit build logs as docx attacments. It's against all known, established conventions. Build logs are plain text, nothing more. |
Alec I can build locally using a series of typed commands, or my batch file, but as I have said before, having "--config" with this command does not work and so the batch files included don't really work either.
This does work. If you really want the repository, it is here, I haven't yet pushed it, but will shortly, because the local build does work. |
Everything built except xenial Is the script outdated for xenial now?
|
Drop xenial, the upstreams are dead. It is already dropped in master. Edit .circleci-config, easiest in the very end which defines the jobs. |
OK, Thanks. Will do. |
For tag push VDR-v1.3.17-beta3 we have 13 files upload to Cloudsmith beta Yet I only found 11 in the auto branch. Circleci produces 10 metadata. - deploys to plugins "auto" Drone shows for raspian arm 1 and 2
So something is using an old version of cmake that is not accepted? |
Sometimes if you wait, errors go away like magic (This doesn't really happen in the real world does i?) It seems to have happened. Python was found and Drone has now fixed the two missing raspbian builds and they appear to have built properly. https://cloud.drone.io/rgleason/vdr_pi/65/1/2 Circleci was successful https://app.circleci.com/pipelines/github/rgleason/vdr_pi/216/workflows/76edcb0c-d68d-414e-bdf3-fa880d6fba3b and so was Appveyor Now Cloudsmith shows 13 metadata file for this https://cloudsmith.io/~opencpn/repos/vdr-beta/packages/?q=VDR-v1.3.17-beta3+metadata Now I can make a master "prod" tag and push |
Good. As for the local builds, they work out of the box when I clone vdr_pi, applies update_templates (just to be sure...) and runs the build as described in INSTALL.md. Attaching log. Possible problems might stem from having a broken %PATH%. There is really n way the build script can handle that as far as I can see. That said, the handling of %PATH% has been made more robust in recent updates, but it should no affect that much. |
Well, I agree that is difficult to build a script that can handle.... Perhaps the line is where the problem is. perhaps vcvars32.bat should be checked. vcvards32.bat is a big file. This looks ok to me. |
That line does not live in either INSTALL.md or build_deps.bat. Why is it executed at all? |
OK, they are in the Shipdriver*clone.bat files. But these are not used in the documented build in INSTALL.md. Please stick to that as long as there is problems |
Ok, now I tried the final push to build and deploy and it fails for some reason. Then I tried building locally again, and I am getting
It's getting late. I am going to leave this for tomorrow morning....discouraged now. |
CMake error : Could not open file for write in copy operation C:/Users/fcgle/source/vdr_pi/build/VDR-remove [C:\Users\fcgle\source\vdr_pi\build\tarball-conf.vcxproj You have somehow a write-protected file. Don't blame the templates for that. First try: Restart the build after removing each and every file under build. As I said, this works out of the box for me. EDIT: And make sure that you really remove everything... |
Yes, I do always remove all files under the build. Will try again. |
Here is the PATH i start with when I encounter troubles. (windows PATH handling is a complete mess...)
nothing more is required, but you might need to reinstall python using choco to get those PATH elements in place. |
Thanks Alec I will check the Environment PATH and make sure. And perhaps reinstall python with choco. although I thought it updated. Will check. ---Tomorrow morning when I am fresh. I incremented the version and pushed a tagged v1.3.18-beta https://github.com/rgleason/vdr_pi - They all look like they built. https://app.circleci.com/pipelines/github/rgleason/vdr_pi/221/workflows/a4455105-b712-40df-a573-0889bbf219f1 https://github.com/rgleason/plugins/tree/auto/metadata |
All builds for me... |
That's good. |
You did not read the updated INSTALL.md, right? The first step in the updated process is to invoke minimal-path.bat, I cannot see that you did? And yes, you should clean up build before that. |
I did execute minimal.bat. Then realized that it wipes out all my paths which is not what I intend to do. I went to look at my environment and found it was untouched. Do you know if there is an easy way to save my current env first? I am setup to build TP template too. I will check on this question tonight. Also I have wxwidgets-3.1.2 located at user/fcgle/source/ PS i did review install.md too |
You can just open a new CMD window. It does wipe the PATH, but not the persistent parts in the registry, just the one in current session. As long as you don't run it there is not much else to say than that it works for me but not for you. We must find a way where things works the same way for both of us, and that way is by definition to throw away everything not used by the build. Don't blame me, blame the Windows "designers" way back in the 80'ies. |
Thanks, Alec "it just changes that CMD window..." very helpful. Just got back will run it all again in a little while. Hope it works! |
1. Removed all files in "build" dir (normally I do this always.)2. Ran minimal-path.bat
3. Ran win_deps.bat
Build Following the Install.md
This worked================ Run bld.bat from source/vdr_pi
|
Running win_deps.bat requires administrative privileges on the first run, when it needs to install stuff. Seems that this is the first problem about failed installs in win-deps.bat. Is it? EDIT: Yes, this should be in INSTALL:md. |
Running bash as administrator from vdr_pi using ./buildwin/<batch.bat.
Change to the "build" directory and remove all files
Then from the empty "build" directory execute
|
I also think in the Install.md the exact paths or directories that should be used for the batch files should be explained. |
So, it works, as I suspected. The paths are explained. I f you read the complete document you find this line in the beginning:
Although in bash/git-bash syntax this should be pretty clear: paths are relative from the build directory. It cannot really be in any other way, since the location where user clones the plugin is arbitrary. Could add the corresponding line in CMD parlance, though. |
You can git rid of the warnings like |
With this we should close this, right? |
Last Night I incremented the plugin to a new version in Plugin.cmake, 1.3.19.0 then tagged it and pushed
Everything built I think and there are only 13 metadata files (is this correct?) Unfortunately I forgot to remove rgleason/plugins/auto and update master and then checkout auto, so that didn't really work, but that repository shows only (11) v1.3.19 metada
It is missing raspbian-9.13 and raspbian-10 that did not get pushed to rgleason/plugins/auto for some reason. |
I am just going to push all these metadata to plugins by hand now. |
The first post is serving as my Sequential List of what to do. |
There is no such need. The only time you need to reset rgleason/plugins/auto is when rebasing to use beta instead or master or the other way around. Otherwise, just leave as it is, the commits will accumulate but this is as designed an no problem at all. You need to rebase things when doing a PR, but only then and as described in Making a Pull request.
Then we need to sort this out, finally. I wrote some description for how to do this here. Could you please apply this, so we can rid of the uncertainties? |
Needs an update. No need in general to remove/rebase the auto branch although it does not hurt. And please remove the build instructions which overlaps INSTALL.md. Just leave the reference to that file since it will evolve over time. In fact, it already has, making your build procedure broken from next commit; we are on master branch. In general, please don't copy contents from the documents you link to. This will fail each time they are updated, and it happens all the time. Just have the links, possibly with some text about where in that link, clarifications, etc. Less is more. |
Just remove all of them, and any other directory with warnings. The warning basically says the this is junk -- things in this directory are supposed to be python libraries. I guess this junk perhaps always has existed, while the warning is new. |
Later, I will copy my first post to my VDR_pi Issues, make a link to this Issue and then close this issue. |
Removed all site-packages with "~" and "~~" which was about 38mb! Thanks. Have to go to boat to measure for a new wet muffler. |
Had the wrong name for GIT_REPO in drone.io for two raspbian. |
https://github.com/rgleason/vdr_pi https://cloud.drone.io/rgleason/vdr_pi/75/2/2 Raspbian arm 1
https://cloud.drone.io/rgleason/vdr_pi/75/2/2 Raspbian arm 2
So what file is mssing now? |
Now it looks like there are extra raspbian files! |
Normal Sequential Process after the plugin is setup and running.
See https://opencpn-manuals.github.io/main/AlternativeWorkflow/InstallConfigure/GithubPreps.html
For builds targeting the master catalog: drop possible existing auto branch and create a new on top of master:
Note: this does not need to be done each time.
Update SD Template with script "update-templates"
https://github.com/Rasbats/shipdriver_pi/blob/master/UPDATE_TEMPLATES.md
See "2. Run the script" https://github.com/Rasbats/shipdriver_pi/blob/master/UPDATE_TEMPLATES.md#2-run-script
For example to update using a tag when in Windows OS
"C:\Program Files\Git\bin\bash.exe" update-templates sd3.0.2
Build Locally and test
https://opencpn-manuals.github.io/main/AlternativeWorkflow/usage.html
Read the Install.md file for complete instructions.
Run the batch files locally, creating the tarball in the build directory.
From Bash Prompt started with administrative rights.
https://opencpn-manuals.github.io/main/AlternativeWorkflow/InstallConfigure/GitHub.html#_building_the_plugin
First create a tagged beta build, using the tag (in this case) "v1.3.19.beta" then a tagged build.
To DEPLOY using Tags
Check the Metadata that has been automatically pushed to plugins/auto branch (Not necessary, Alec Lemas)
https://opencpn-manuals.github.io/main/AlternativeWorkflow/InstallConfigure/GitHub.html#_check_the_metadata_push
Making a Pull request. https://opencpn-manuals.github.io/main/AlternativeWorkflow/InstallConfigure/Catalog-Github-Integration.html#make-PR
If metadata files are missing, check the "builder" logs. Usually it is a bad auth key.
The text was updated successfully, but these errors were encountered: