Question: what happens with old or "invalid" tags?

[fnagel]

I'm using your awesome script to auto deploy to TER via tag pushing (ExtensionRelease). Works great so far but I'm having two questions before using this on some older extensions of mine.

• What happens with old, existing tags when the hook is installed and new tags are are added?
• What if there are existing (or new tags) that are "TER invalid" (eg not in a format like 1.2.3) like "last-4.x-version"

Thanks for your ongoing support of the TYPO3 community and providing such tools!

Yours Felix

[xf-]

Hi,

looks like a version check is missing. Only the current head is checked for tags. https://github.com/NamelessCoder/gizzle-typo3-plugins/blob/master/src/GizzlePlugins/ExtensionRepositoryReleasePlugin.php

[fnagel]

So it would try to push all tags, incl. old and invalid. I would assume the TYPO3 TER won't re-release existing versions and checks for a valid version number?

[xf-]

Hi,

no. My understanding is the last commit will be tested against a tag. Also the behavior on multiple tags for one commit would be interesting.

git is really simple inside. All tags are in a folder with name and commit Id inside.

I think the remaing questions are best reserved for @NamelessCoder ;)

[NamelessCoder]

Hi Felix,

Nice to see you got it working :)

The answers to your questions are part TER errors, part GitHub, part Gizzle behavior. I'll try to describe all the possible failures and what Gizzle will do with them.

• GitHub only sends the push event when you actually push. If you GitHub repository already contained the tags, nothing happens. If the tag is new (e.g. if something is actually pushed), then one new event is generated for each tag that is new. This means that if you migrate your repository from somewhere else to GitHub, you should probably do that before you add this hook.
• Gizzle will attempt to release every tag for which it receives a payload from GitHub - neither Gizzle nor the upload library cares if the version contained in the tag, was already released, if it is invalid or if it is older than the newest release. TER checks this after upload is completed.
• TER will accept uploads also of older versions - if that version was not already uploaded. This means that Gizzle can actually upload a complete batch of versions simultaneously, if you "publish" several git tags at once.
• Gizzle does not check anything about the tags - it will attempt to upload anything and the tag does not have to be numeric for it to work. In actuality, Gizzle completely ignores the composer version and tag names. The only things that are relevant, are the folder name (by default, repository name) because that gets used as extension key - and the version recorded in ext_emconf.php. But they're not relevant to Gizzle itself.
• The TYPO3 Repository upload library will use the folder name as extension key when uploading. Gizzle will try to check out the repository using a folder name that is either manually configured (see https://github.com/NamelessCoder/typo3-repository-gizzle which accepts the extension key as an URL parameter).
• The TYPO3 Repository upload library will fail before upload starts if no ext_emconf.php file exists.
• TER itself will reject the upload after it has hit the server if:
  • Credentials are missing/incorrect.
  • Version number in ext_emconf.php already exists as TER version.
  • Version number in ext_emconf.php is invalid format.

Every failure is reported as response for the webhook request - and every failure that can occur while or after checking out the target repository, will be reported as GitHub comment if you also placed a .token file in your project.

Successful releases are reported as response for webhook request and as GitHub comment if you have a .token.

When Gizzle comments success/failure on GitHub it will always do so on the commit that is HEAD of the tag identified in the payload from GitHub.

Finally: Gizzle sets the status code on the HEAD commit before the checking out of the repository begins and sets it to error if any errors occur - and sets it to success if the upload script succeeds.

Hopefully that explains the ins and outs - if not, feel free to ask more questions!

[NamelessCoder]

PS: This is what a release commit comment will look like - it's not exactly pretty yet, but it conveys all the necessary information from all steps of the execution:

https://github.com/NamelessCoder/uploadtest/commit/cff25c892dc67bfb8e20f2854eb9be739ed5e04b

[fnagel]

Wow, thanks a lot. That's really detailed information. Perhaps this should be linked from the readme. Helps a lot in understanding what happens here.

So, my conclusion would be:

• Push old tag before adding Github hook
• Change version in em_conf.php to something 1.2.3-dev after each TER deploy

This should prevent any non release tags from being uploaded to TER.

ps: Already took a look at your uploadtest repo :-)

[NamelessCoder]

Both conclusions are correct - the only thing to note is that it does put a little bit of unnecessary pressure on TER/gizzle when those -dev tags are used. I will extend the release plugin with a version validity check before pull is performed so that doesn't happen at all :)

[NamelessCoder]

That should do it - https://github.com/NamelessCoder/gizzle-typo3-plugins/commit/fcfe9c0960dc50924300cf0c63cf93337c8af01b

[fnagel]

Wuuuhh, very nice -- now its noob save :-D

[NamelessCoder]

As we say in Danish, it "wears suspenders and a belt" :)

[fnagel]

Due to a little accident I know for sure TER accepts version numbers like 1.2.3-dev in ext_conf.php.

So, one should not alter the version number in em_conf.php after each TER deploy.

[NamelessCoder]

Oops - maybe that should be considered a TER bug. Or I'm missing the practical reason for needing to allow some un-comparable version string... either way, assuming I did it right, an updated gizzle-typo3-plugins should reject those bad versions and prevent the upload.

[fnagel]

either way, assuming I did it right, an updated gizzle-typo3-plugins should reject those bad versions and prevent the uploa

It should prevent bad git tags but not bad version in em_conf.php.

[NamelessCoder]

Right! That's the case it won't catch. I guess I could make typo3-repository-client enforce the same preg matching - it already reads the version from emconf.

[NamelessCoder]

So, I went ahead and did that :)

https://github.com/NamelessCoder/typo3-repository-client/commit/51e4b17dd685c30c0434493d70400b6bf9a19723

Signing off for today - sleep tight!