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

Adds actions workflow #112

Closed
wants to merge 11 commits into from
Closed

Adds actions workflow #112

wants to merge 11 commits into from

Conversation

ebh
Copy link
Contributor

@ebh ebh commented Dec 27, 2020

Note: I'm pretty new to continuous integration (CI) for Go modules. I saw a couple of different ways it could have been done but was unsure which was the best. So just picked one so I could raise a PR to start the discussion about what is the best way to proceed. So open to feedback :)

In #111 I raised the problem that tests were failing and suggested the idea of using GitHub Actions to run the tests.

This PR adds configuration to do that, run the tests using GitHub Actions to run the tests, not fix the tests that are failing.

The tests are run several times, once each for:

  • Go versions: 1.12, 1.13, 1.14, 1.15
  • OS: MacOS, Windows Ubuntu
  • As a whole and each these file individually
    • Running the files individually is meant to temporarily only, while there are multiple problems with the tests failing

Because the tests need a Bitbucket (BB) account to run tests against I created a new BB account saved the details using Github Actions Secrects. This will need to be repeated in the Settings of the ktrysmt/go-bitbucket, which I don't have access to.

@ebh ebh mentioned this pull request Dec 27, 2020
@ktrysmt
Copy link
Owner

ktrysmt commented Dec 27, 2020

Thank you for your suggestion. As you say, tests that require an account secret (id / pass) are integration tests, not unit tests, exactly. I am considering. If we should check the library as integration test the secret should be setted to an action but it needs a real bitbucket account to run integration test.

Until today, the ./tests/ dir was only for my private local test that was meant to be a quick check of how the library works.

I think that the people who have contributed so far also made pull requests after actually performing the integration test at hand and confirming it.

Or if we should do it as unit test, write fixtures and create unit test's codes in it. But it would may be heavy for us.

I'll think about how to maintain the quality of this library for a few days.

And then, supported version of go are only 1.14 and 1.15 in present. golang project is support two newer major releases. should remove 1.13 and 1.12 from the configuration.

@ebh
Copy link
Contributor Author

ebh commented Dec 27, 2020

I've changed things so only Go versions 1.14 & 1.15 are tested.

As mentioned I'm pretty new to continuous integration (CI) for Go modules, but I'm also pretty new to Go in general. However, I'm very keen to learn more, in particular testing. And nothing makes you learn faster than doing :)

So I'm happy to devote some time to writing unit tests and raising the PRs for them. Provided you can give me constructive feedback so I do a good job :) At this stage, I probably devote the equivalent of 5-6 full days over the next 4-5 weeks.

@ebh
Copy link
Contributor Author

ebh commented Jan 5, 2021

Closing as per discussion in #111 & #96

@ebh ebh closed this Jan 5, 2021
@ebh ebh mentioned this pull request Jan 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants