Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move CI for packet-python to cloud.drone.io #81

Open
vielmetti opened this issue Apr 21, 2020 · 4 comments
Open

Move CI for packet-python to cloud.drone.io #81

vielmetti opened this issue Apr 21, 2020 · 4 comments

Comments

@vielmetti
Copy link
Member

In the interests of supporting a public dashboard for CI status for this integration, consider moving this repo to use cloud.drone.io for CI.

Might move this over to cloud.drone.io actually.

Originally posted by @mmlb in #80 (comment)

@mmlb
Copy link
Member

mmlb commented Apr 21, 2020

oops I did not notice that it wasn't set to public. I've rectified that. We can still decide to move over to cloud.drone.io, but it would be for different reasons.

@displague
Copy link
Member

@vielmetti are there other benefits to using Drone on this particular project?

My latest comment in #58 reflects an interest in using Github Workflows for this project. I'm sure we can get a release process tied into Drone if it is preferable.

@vielmetti
Copy link
Member Author

@displague

Drone Cloud is a pretty well-known quantity here and it runs on Packet infra, so we'd have some folks who already knew what was what there.

There is a known architectural issue with Github runners on public repos, see https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners#self-hosted-runner-security-with-public-repositories for that discussion.

@displague
Copy link
Member

displague commented May 26, 2021

By avoiding E2E testing and using mocks (#93 would be nice to have), we can avoid the need for secrets in testing PRs.

Release PRs can be made with branches on this 'origin' repository (only possible by maintainers who already have access to the relevant secrets).

This approach is in place for packngo and seems to work well enough.

The Terraform provider takes a similar approach, but E2E tests are run only run on the 'origin' branches. We don't have anything in place to authorize user branches to be tested in this way.

I'd like to close this issue out in favor of what is already in place with:

Semi-related, I have been noticing that drone is still executing against PRs in this project, even though .drone.yml has been removed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants