Use common code for constellix API interaction, prepare auth for v4

[istr]

Fixes #41.

[istr]

@ross @viranch I thought that it might be a good idea to prepare the larger #35 / #39 with smaller PRs that are easier to review and could be merged more quickly.

[ross]

Overall seems good. Couple comments/questions inline.

Will hold off merging until you say so.

[ross]

Looks good. Will hold clicking the green button until you say so.

Any interest in having commit/merge access? Either temporarily or permanently? For this repo or the org? You've been involved enough at this point that it probably make sense, but up to you. The only requirements are that you show up every now and then and review stuff for others and get reviews from others for anything nontrival or potentially impactful.

[istr]

@ross

Looks good. Will hold clicking the green button until you say so.

Thank you. Go for it, I checked against the real API and it works for me.

Any interest in having commit/merge access? Either temporarily or permanently? For this repo or the org?

Thanks for the offer - it is an honor. If you think it makes sense, I could see myself doing a little more maintenance on this one. As for the other providers, I only really use ns1 in production and am now starting to tinker a bit with gcore and https://github.com/istr/octodns-cloudns (which could also be moved to the octodns org when it is ready).

However, feel free to add me as a regular reviewer (w/o write access) for the org.

Before making any of these changes, please ask the rest of the org if there are any objections. 😃

[ross]

Thank you. Go for it, I checked against the real API and it works for me.

You should have the perms once the invite has been accepted.

[istr]

Thank you. Go for it, I checked against the real API and it works for me.

You should have the perms once the invite has been accepted.

@ross OK, thank you. Could you please guide me on the merge policies for octodns org for this first merge?

• squash or rebase with all commits?
• how to update the CHANGES - manually or from commit messages?
• what to do for release tagging?
• how and when to publish to pip?

[ross]

• squash or rebase with all commits?

Std practice is the GitHub default "Create a merge commit." This basically follows GitHub Flow as practiced internally. PR is the main source of general history and the commits show the details of how things got there (and aren't linear or anything.)

• how to update the CHANGES - manually or from commit messages?

CHANGELOG.md updates are manual. Can be done in a stand-alone commit or as part of one of the final commits of the branch.

• what to do for release tagging?

Process is a commit & PR that updates __VERSION__ in octodns_<module>/__init__.py and finalizes CHANGELOG.md with the date and a descriptive &| funny title. If any changes slipped through w/o changelog entries they can be added too.

Once the PR is reviewed it's merged normally and...

• how and when to publish to pip?

The repos have ./script/release in them that is run once the PR is merged and the local copy is back on main. It does all the pieces necessary to tag, build, and upload things. That said you don't have pypi permissions on the modules so you won't be able to run it.

For now you (or anyone else who wants a release of something) can just open the PR in the repo I can merge and release (hit by a bus-wise I'm not the only one w/perms 😁)

[istr]

@ross ok, I'll then leave the versioning and publication up to you. I thought that publishing would be done using some "automagic" interaction between commit tags and github actions.

[ross]

I thought that publishing would be done using some "automagic" interaction between commit tags and github actions.

I thought about looking into something like @parkr set up for the docker stuff to do it, but never got around to it and it only takes about 30s to do when the time comes so I haven't bothered 😁