Wrong download links in ocpn-plugins.xml at plugins repo.

[leamas]

Trying three or four links from current metadata/Ship* files in the plugins' project master branch reveals that links are broken. So far none tested seems ok.

Perhaps the artifacts at cloudsmith are gone, superseded by new builds? That is, the links once did work but not any more?

Trying in my own repo the links generated in the metadata looks ok and can be downloaded.

When I designed the upload long time ago the intended workflow was to have two separate cloudsmith repos, one for untagged builds and one for tagged. The idea is that the tagged builds represents stable versions which should be kept for "long" whereas the untagged builds are unstable test versions which could be thrown away after a short time.

Now, it seems like you tag each and every build, basically making this workflow impossible. Is this, bottom line, a sign that the workflow needs to be revised somehow?

Ot just some trivial bug?

[leamas]

Hm... If I understand this correctly, the situation is that you have made new builds in the prod repo, but havn't got a PR against the plugins project merged?

Just a guess...

[Rasbats]

You guess correctly... the last PR for the plugins project at OpenCPN was 2.5.52. I held off making another PR until I had fixed the RouteDialog unowned widgets issue.

It is probably my bad practice of tagging that causes confusion but if you look at Jon's Testplugin the same is happening there. I know I should retrieve old code from the commit history but... I am using the tags as bookmarks.

[Rasbats]

The big issue is that the beta catalog is not being used. The only entries are for PyPilot and Testplugin. How do I use this catalog? How is the metadata produced for a beta version?

Appveyor fails for the tagged build but the 'Master' build still arrives in Cloudsmith for both beta and prod repos.

I think some guidance is needed on all of this.

[Rasbats]

Looking at Cloudsmith both beta and prod have metadata for any plugin at the same version level. Should this be the case?

[leamas]

Wasn't the 11:th commandment Thou shall not use tags as bookmarks?...

Seriously, it's a habit strange enough to cause problems.

Looking at Cloudsmith both beta and prod have metadata for any plugin at the same version level. Should this be the case?

Probably not. Why not try it from another angle: how do we want things to work, really?

My initial design was to have two repos 'stable' and 'unstable'. The idea was to basically keep everything in stable for "long" , even for users with outdated catalogs. And that builds in 'unstable' are more or less temporary, depending on storage size and number of builds.

Also in this schema all builds are untagged from the beginning. When built, the should end up in the 'unstable' repo.

At certain points a build is to be released. This is done by tagging it and making a new build. This build will then end up in the 'stable' repo. Tagging a build is not done lightly, tagging is the same as creating a release.

I'm not really clear about the Beta in this schema. Should builds in Beta also be tagged, kept in the 'stable' repo? Or untagged, and kept in the unstable repo, with the risk that they will disappear.

It is of course also possible to look at the tag, and send all tagged builds where the tag matches 'beta' to a separate Beta repo. More complexity, is it worth it?

Again: let's not focus on how this works today, it's clearly broken. Question is how we want it to work.

Thoughts?

[leamas]

hm... looking at Jon's code we find this snippet:

# Builds are uploaded to one of PROD, BETA or ALPHA repositories
# The repository depends on the branch and use of tag to determine which repo.
# ALPHA: Non-master branch no tag
# BETA: Non-master branch with annotated tag
# BETA: Master branch no tag
# PROD: Master branch with annotated tag

So besides the initial tag/no tag selection he also uses the git branch to select repo. The basic question is the: do we want to use two or three repos?

My gut feeling is that two should be enough. Guts should not really be trusted, though.

[leamas]

Sorry for thinking aloud, too much text. That said, my proposal based on above (and some more thinking):

• We keep Jon's idea with three repos alpha, beta, prod.
• You stop your habit of tagging each and every build, instead tagging only releases.
• Untagged builds goes to the alpha/testing/unstable repo.
• Tagged builds with a tag matching beta goes to the beta repo.
• All other tagged builds goes to the prod/stable repo.

Thougths?

[Rasbats]

My habit of tagging each and every build will now stop! (Note to self)

Your proposal makes absolute sense. I would like other interested parties to be involved in this discussion. Could you raise this as a new issue for OpenCPN/plugins?

[leamas]

I could... but perhaps this is not the time. Nothing of this affects the contract between the plugins project and the separate plugins, so here is not much to discuss. We do the same thinǵs as others, just in a somewhat different way.

And if someone should raise an issue here, it might be better if you file the bug.

Instead: let's investigate where this takes us. I will try to make some code, it shouldn't be that complicated.

[leamas]

I could... but perhaps this is not the time

If you want me to expand on this, please send me a PM at leamas dot alec AT gmail

[leamas]

The big issue is that the beta catalog is not being used. The only entries are for PyPilot and Testplugin. How do I use this catalog?

Jon's original idea is based on both branches and tags, see above https://github.com/Rasbats/shipdriver_pi/issues/82#issuecomment-735666643. I find this too complicated. Many devs like you only work in a single master branch, and there is no reason to force a specific branch structure on those.

The current idea is simple enough, repeating myself: Any commit with a tag containing the string beta goes to the beta repo. I find this natural, beta commits does normally contain this string. Also rc is used, we could easily extend the logic to handle also this if need be.

[Rasbats]

Now testing the different builds.

Alec... What method do you recommend for removing all those releases that are filling the GitHub pages? Happy to use Linux or Windows but I don't want to do it one by one.

[leamas]

Hi,

Sorry, I missed this (too much email... to handle)

You can remove remove upstream tags from the command line, this is much more efficient. The basic command is:

$ git push origin :refs/tags/<tagname>
$ git tag -d <tagname>

which deletes a tag with name tagname both on the git repo and locally. If you want to delete all tags (really all) I assume you could do something like

$ for tag in $(git tag -l); do  git push origin :refs/tags/$tag; done
$ for tag in $(git tag -l); do  git tag -d $tag; done

[leamas]

Hi,

Anything new here? Have you tested tagged/untagged releases and checked and that they go to proper repos?

[Rasbats]

Tested a couple of days ago and everything went to the correct repo.

Just one question. What happens to get the beta into the beta catalog? The tarball name includes the string beta but not the metadata file. Or does this need something changing in the OpenCPN base code? Out of laziness I have not traced Jon's testplugin repo method.

I want to follow through and now update the master catalog. Intend doing this tomorrow unless you have something for the beta catalog process that needs testing.

Thanks for the fix with mingw. All compiled fine with my last build.(2.5.61)

[leamas]

Just one question. What happens to get the beta into the beta catalog?

Tag with a tag containing the string 'beta', like 2.5.6-beta1. The name of the tarball is not involved, it's just about the tag.