publish using github release version

[gita-vahdatinia]

Description:

Previously workflow did not run on main because the key setup: true does not allow multiple workflows.
Tested by creating tag v2.6.15 and setting it to gv-main-branch-filter -- see pipeline here that triggered a publish workflow
From Circle docs:

New version created here

CircleCI Dynamic Configuration, formally known as Setup Workflow, allows for a maximum of 1 workflow in the initial setup workflow. So if setup: true is set then the following config would be invalid:
Note: More than one workflow can be defined within a dynamic config, and the above error can be avoided as long as conditional parameters are set so that only one workflow will be executed.

To fix we added a filter mechanism on the tag level; this release tag also corresponds to the new version of the orb.

Also updated the docs and added in a filter mechanism to work with the git tag; since the git tags are not able to be filter it just looks if it begins with v; however, the tag needs to have the format of vX.X.X in order to publish a new version. See CI thread here
We have to add this filter on both the workflow level and the job level of the publish workflow because there is a bug in [CircleCI] (circleci/circleci-docs#6148 (comment))

The New Workflow for Publishing Production Version Orbs
When an orb is merged the author needs to create a new release tag off of main. After it is created, this new tag will trigger a pipeline run to publish the new orb with the same version as the github tag version. The version must be in the format of vX.X.X
Previously; we would update the version of the orb using the PR body and including a semver version in the title; the orb would read the PR's title and update based on that.
To Do:
add descrion for /continue workflow and test-deploy
Note:
Lots of commits because each git tag needed a new commit to test

The continuation in the lint-pack workflow is what triggers the test-deploy yaml file. The workflow continues by trigger everything in the lint-pack and when it is completed will automatically trigger test-deploy. Full description of how this workflow work is described in orb-tools here

[gita-vahdatinia]

this workflow will only run when a new tag is created; this tag corresponds to the version of the orb

[harisiva-codaio]

Doesn't this mean that this job will never run?

[gita-vahdatinia]

Itll only be ran on personal branches, so this is the check before you can merge

[harisiva-codaio]

Is the recommended pattern to create the tag to have the author do it locally, and then push it up to github?

[harisiva-codaio]

Why this change?

[gita-vahdatinia]

pipeline.project.type is always defined in Circle, I think it's cleaner to use envvar than have it hardcoded

[harisiva-codaio]

How does this test-deploy pipeline get used?

[gita-vahdatinia]

after lint-pack is done, it will trigger test-deploy, so it is part of the personal branch pipeline

[harisiva-codaio]

Can you describe the handshake between this and the main config.yml file, and that this is necessitated by circle.

[gita-vahdatinia]

Is the recommended pattern to create the tag to have the author do it locally, and then push it up to github?

I think it's easier to create tags off of the UI personally, that's how I instructed it in the README; but they could create it locally

[gita-vahdatinia]

Is the recommended pattern to create the tag to have the author do it locally, and then push it up to github?

I think it's easier to create tags off of the UI personally, that's how I instructed it in the README; but they could create it locally

but the overall pattern to have it be updated this way was from orb-tools

[harisiva-codaio]

Can you add a comment here referencing the test-deploy.yml file and the workflow there?