Automate deployment to python-nameless

[ionelmc]

Currently python nameless has just a few branches that I manually build from time to time.

There could be automation to push branches from pylibrary's CI.

However the test projects are ugly (weird values) and env names (that would translate to branch name) are also ugly. I guess that'd be fine.

PRs could build prefixed branch names (@dHannasch).

[ionelmc]

One thing that I do when I manually update python-nameless: I look at all the diffs. That would be pretty hard to do on 100-something branches. Maybe it should be a different repo ...

[dHannasch]

Hmm...when you did that one pull request a bit ago, this seemed to work fine:

$ openssl aes-256-cbc -K $encrypted_a70d5afca909_key -iv $encrypted_a70d5afca909_iv -in publish-key.enc -out ~/.ssh/publish-key -d

The command "openssl aes-256-cbc -K $encrypted_a70d5afca909_key -iv $encrypted_a70d5afca909_iv -in publish-key.enc -out ~/.ssh/publish-key -d" exited with 0.

But for the later pull requests I've been making, the variable $encrypted_a70d5afca909_iv is undefined:

$ openssl aes-256-cbc -K $encrypted_a70d5afca909_key -iv $encrypted_a70d5afca909_iv -in publish-key.enc -out ~/.ssh/publish-key -d

iv undefined

The command "openssl aes-256-cbc -K $encrypted_a70d5afca909_key -iv $encrypted_a70d5afca909_iv -in publish-key.enc -out ~/.ssh/publish-key -d" exited with 1.

I assume that the $encrypted_a70d5afca909_iv is set somewhere and that's why your build was able to succeed.

I wonder if it could literally have something to do with who makes the pull request...although I don't see how that's possible, since it's ultimately running on the same server either way, so it should still be able to access the secret, I would think. Indeed it's literally the same user account accessing the Travis server, so...yeah, no idea why the secret is inaccessible.

[Querela]

If it's still an issue.

Maybe it's for security reasons, and it is updated/set to not be accessible for pull requests?
It is theoretically possible to make a pull requests that updates the Travis-CI config to dump those private environment variables. And that would be bad. In travis you can specify where those variables can be used, e.g. only the master branch. That should disable it for pull requests, I would guess.

[ionelmc]

This has sorta been solved. Currently there aren't so many branches, master builds and prs should push stuff there. At least if something didn't break with travis, which sadly happens a lot :-)

[Querela]

Ok.
Yes, my travis jobs ran out of memory. Restarting a few days later they worked again ...

The project should probably also move to travis-ci.com, as the .org one will shut down. See

• https://docs.travis-ci.com/user/migrate/open-source-repository-migration#what-will-happen-to-my-travis-ciorg-repository
• https://docs.travis-ci.com/user/migrate/open-source-repository-migration#q-what-will-happen-to-travis-ciorg-after-december-31st-2020

It might be possible that the automatic redirection they wrote about will work but not sure when they will enable it? The repo icons should be updated, I guess?

https://travis-ci.com/github/ionelmc/cookiecutter-pylibrary/builds
(No builds for now.)

[ionelmc]

Yes we have to update the .com stuff soon, it's on my pretty unreliable todo list :-)

[ionelmc]

Travis.com migration should be done.