ci: replace travis with actions, setup renovate

[gr2m]

fixes #1692

[gr2m]

it looks like the fact that the tests are ran on GitHub actions somehow interferes with the tests.

This is the last step to setup renovate across @semantic-release, would be great to get this fixed. I can have another look next week, but any help is welcome

[jsoref]

That's correct. Adding a couple of env vars takes the error count from 8 to 3:

4c733f4

The error I hit involves an unexpected URL -- happy to return the adventure to you :-).

[gr2m]

That's correct. Adding a couple of env vars takes the error count from 8 to 3:

4c733f4

The error I hit involves an unexpected URL -- happy to return the adventure to you :-).

Thanks a lot! Applied via 1f71b2b

[gr2m]

I think I got it 🤞🏼 mocking the environment variables by setting values to null results in the env variables to be set to the string "null", which causes false positives.

[gr2m]

I think I got it 🤞🏼 mocking the environment variables by setting values to null results in the env variables to be set to the string "null", which causes false positives.

that didn't work, but I'm pretty sure the problem is caused because GITHUB_ACTION is set, which causes slightly different behavior in @semantic-release/github: https://github.com/semantic-release/github/blob/c16f315cac8c541b5b923e6c0b102fd75a831713/lib/verify.js#L59-L65

[jsoref]

I think I needed to set:

GITHUB_API_URL: mockServer.url,
GITHUB_PREFIX: 'api/',
to make some amount of progress in this (the latter definitely requires changes to the test to account for the url) -- alternatively, one could try to have two mockServers, but I didn't see enough benefit in that.

I also looked into setting up multiple repo servers, because it felt like tests might be colliding...

[gr2m]

I think we don't want to set any of the GITHUB_* environment variables, we don't want semantic release to get into any CI state

I feel like there is a racing condition:

https://github.com/semantic-release/semantic-release/runs/1737560659#step:7:372

It fails because the request URL it expects for the Dry-run test is /repos/git/test-dry-run, but instead it gets /repos/git/test-js-api", which is from another test

[jsoref]

Yeah, that's where I think you need to use distinct dockers for each test, it's the same fail I'm hitting.

[gr2m]

I don't get the same error locally.

need to use distinct dockers for each test

I don't know how I would even do that right now :D I still hope to make it work, I've changed the tests to run sequentially, let's see ...

[gr2m]

Today I learned: turns out that await execa(cli, [], {env, cwd}) does not use env as exclusive environment variables, it extends process.env, unless extendEnv: false is set. That's why the integration tests all assume they are run in GitHub Actions, although we set Travis as environment.

[gr2m]

I think I got it now, thank you @jsoref, you helped a lot :)

[travi]

is it worth having this as a separate script when it already matches the existing test script? i know we needed it, at least temporarily, in some cases where they didnt match, but seems like that could be avoided here.

[gr2m]

I added it because of pretest. On CI, we run the linting in the separate job, that only runs after the tests passed in all supported node versions

[gr2m]

The main problem why the CI tests started to fail after migrating from Travis to GitHub Actions was that the environment variables set by the GitHub Actions environment sneaked into process.env. I always thought that setting the env option for exec would set all environment variables, but instead it only extends process.env. Setting extendEnv resolved the problem

[github-actions]

🎉 This PR is included in version 17.3.5 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[jsoref]

I claim this is wrong ;-)

[jsoref]

Or perhaps, if it's intended, I'd suggest '**renovate**' and then document that people can test renovate stuff by using a branch vaguely named renovate -- there's no particular explanation anywhere in this PR as to why renovate is special as part of a branch name.

[travi]

We are using https://github.com/renovatebot to keep dependencies up to date and it creates branches that are named to match this pattern. This ensures that these branches trigger this workflow, even in the cases we have configured renovate to not open pull requests (although we still have a few kinks to work out around those cases). This pattern isn't intended to enable any special behavior for outside contributors.

[jsoref]

Ah, that isn't particularly obvious (there aren't enough hints anywhere). Might I suggest a # renovate/* branches are generated by @renovate-bot ?

[gr2m]

great idea! Let's do that! Pull request welcome ;)