Comment 1 Pierre Ossman 2022-09-29 10:42:41 CEST

GCC includes some form of Go support, but our current version of GCC might be too old:

https://go.dev/doc/install/gccgo

Comment 2 Pierre Ossman 2022-09-29 10:49:42 CEST

For packaging go packages, Fedora's guidelines are probably interesting:

https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/

Comment 3 Alexander Zeijlon 2023-06-13 16:20:50 CEST

We have decided that since we do not yet have a working Go compiler in our build system, the best way forward for now is to package the compiled binary that is available at https://github.com/transifex/cli/releases.

Comment 5 Alexander Zeijlon 2023-06-21 14:05:46 CEST

When performing some initial tests with the new CLI tool, it turns out that it cannot make connections over HTTPS form inside cenbuild.

As it turns out, we are not packaging any root certificates, which means that nothing in cenbuild will be able to verify certificates from external sites, unless this somehow comes packaged with the application in question.

Comment 6 Alexander Zeijlon 2023-06-21 14:11:58 CEST

There are currently two applications in cenbuild that need to communicate with external sites, tx (the old version of the CLI tool) and osslsigncode, and we have investigated why these have been working without issue without any CA-certificate present in cenbuild.

tx:
* Turns out that the old version of tx came packaged with its own CA-certs file that it used if no such file could be found in the system.

osslsigncode:
* The only communication it does with an external site is done through HTTP, which means that no CA-certs file is required.

Comment 8 Alexander Zeijlon 2023-07-05 14:00:07 CEST

Package ca-certificates has been added through bug 8176, which is needed by tx for communication over TLS.

Comment 9 Alexander Zeijlon 2023-07-05 14:23:58 CEST

MUST:
 ✅ The cendio-build-transifex-package should provide a CLI tool that is
    compatible with Transifex APIv3.

> A package for a new tx CLI tool (v. 1.6.7) has been built and pushed to our RPM
> repo.
> 
> Note that this version is not bundled with ca-certs and instead needs our new
> ca-certificates package to function over TLS.

 ✅ Compatibility between the new CLI tool and our configs needs to be evaluated, such that, we can be confident that it will be able to pull and push language translations.

> As of the commit in comment 4, all our tx configs have been updated to match
> the new format, required by the new CLI tool.

 ✅ Future updates of the CLI tool should require minimal changes in our build-system.

> The rpm spec-file has been written to require as few modifications as possible
> to the source tar-file, downloaded from Transifex's GitHub page.

SHOULD:
 ✅ The new tool should require minimal external dependencies.

> The new tx version is compiled without external dependencies, except for that
> it needs to have ca-certs available in order to function over TLS.

Note that testing of tx does not have full coverage yet, as of this comment, since it requires valid login credentials.

Comment 10 Pierre Ossman 2023-07-06 14:07:07 CEST

Tested the client and seems to work well. I used our Makefile targets for the client metainfo to upload the .pot file and download the .po files. Everything seems to have transferred correctly in both directions.

I did not find any other interesting commands in tx to test.

> MUST:
> * The cendio-build-transifex-package should provide a CLI tool that is
>   compatible with Transifex APIv3.

Yes, seems to communicate without issues.

> * Compatibility between the new CLI tool and our configs needs to be
>   evaluated, such that, we can be confident that it will be able to pull
>   and push language translations.

I did not have to change anything, so configuration files seem to have been migrated correctly. I ran "tx status" in client/metainfo/, client/tlclient/, and tlmisc/ and there were no complaints.

> * Future updates of the CLI tool should require minimal changes in our build
>   system.

Not a strong requirement IMO, but it's always nice for things to be easy to maintain. The spec file is very minimal, and I can't see any need for complex manual steps. So this seems fulfilled.

> SHOULD:
> * The new tool should require minimal external dependencies.

Also not a strong requirement IMO. Dependencies are fine if it helps keep things simple.

In this case, the dependencies are almost non-existent as the binary is statically linked, and the installation of it is a simple copy. So this is fulfilled.