> On 18 Feb 2020, at 10:13, Tino Pyssysalo <tino.pyssys...@qt.io> wrote: > > On 14.2.2020, 22.17, "Thiago Macieira" <thiago.macie...@intel.com> wrote: > >> On Tuesday, 28 January 2020 19:31:34 PST Thiago Macieira wrote: >>> On Tuesday, 28 January 2020 03:52:49 PST Tino Pyssysalo wrote: >>>> It is also possible to transfer the qtaccount.ini file to a CI machine, >>>> which removes the need for manual/interactive login. The qtaccount.ini >>>> just >>>> contains the hash of the password. >>> >>> I suggest you be very careful in suggesting how to transfer the >>> qtaccount.ini file. Test half a dozen public CI systems and give >>> instructions to them all. >>> >>> And specifically tell people NOT to "git add" it to a project on GitHub/ >>> GitLab/BitBucket. >> >> Hello Tino >> >> Can we get an answer here? >> >> What is the recommended way to install Qt on a CI to test a Qt-based >> application? >> >> Travis CI has stopped working completely and I'd like to switch to GitHub >> Actions. Does The Qt Company recommend I use Stephan Binner's PPA? Or does >> it >> want me to use its own compiled binaries? If the latter, please provide >> instructions for automated builds. > > Actually, we do not have a good support to install Qt on a (public) CI. > Currently, it's > done with scripting: ./installer --script myScript.qs > > However, this does not solve the issue of providing the credentials. It is > possible > to read credentials from the environment variables > https://doc.qt.io/qtinstallerframework/scripting-installer.html#environmentVariable-method. > > BUT WE DO NOT RECOMMEND anyone to upload the credentials to CI, even > If it is possible to hide them in GitHub. > > The next installer (4.0) will allow accessing qtaccout.ini via the env > variable, > but it's still heavily under development. > > Meanwhile, the JWT token in qtaccount.ini could be possibly used as a session > Token, but we need to investigate this further. > > As I said not a good solution right now, but we'll study a few workarounds > to have a better support right now. > > Controller.prototype.CredentialsPageCallback = function() > { > var page = gui.pageWidgetByObjectName("CredentialsPage"); > > /*** Login widget */ > page.loginWidget.EmailLineEdit.setText(); > page.loginWidget.PasswordLineEdit.setText(); > > Or using signup widget > /*** Signup widget */ > page.signupWidget.SignUpLineEdit.setText(); > page.signupWidget.SignUpPasswordLineEdit.setText(); > page.signupWidget.SignUpPasswordVerifyEdit.setText(); > page.signupWidget.ServiceTermsCheckBox.setChecked(true); > > gui.clickButton( buttons.NextButton); > } > -- > Tino Pyssysalo
Secret management in automated systems is not a new problem, and not specific to the Qt installer. If your CI pipeline is actually a CD pipeline that deploys to production, then you need to manage secrets. These are hard problems, and you shouldn’t reinvent the wheel here. Secret management tools exist already, such as Hashicorp’s Vault [1]. The Qt installer needs to work with those solutions; making secrets available via environment variable is ok, but those should be access tokens, not someone’s username/password. Which means that the server side needs to allow users to manage their tokens. In a CI/CD pipeline that depends on 3rd party packages like Qt, it’s a good idea to manage your own artefact/package repo, so that you have control over the versions you are building and testing against - or at the very least to become independent of 3rd party infrastructure that you have no control over, but might block your build or deployment. Volker [1] https://github.com/hashicorp/vault _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
