skekauoha / salty-cypress-testrail-reporter

MIT License
5 stars 21 forks source link

Wrong runId in `publishResults` #3

Open shifr opened 5 years ago

shifr commented 5 years ago

Hello, thanks for the library. I've run into some issue with the runId passing from options. After debugging the source code I've found that runId is taken from the testrail API but not config file. Could you please check it? For example: As I understand, this code:

if (!this.options.createTestRun) {
      this.runId = this.options.runId;
    }

    axios({
      method: 'get',
      url: `${this.base}/get_runs/${this.projectId}`,
      headers: { 'Content-Type': 'application/json' },
      auth: {
          username: this.options.username,
          password: this.options.password,
      }
    })
      .then(response => {
        this.runId = response.data[0].id;
        publishToAPI();
      })
  1. Sets this.runId from the configuration file
  2. Then fetches the last testRun from the testrail by this.projectId
  3. And this.projectId always equals to 2(it's default value) So it'll always be the wrong runId that equals the last test run from the project(ID=2)

I think this code should look like:

if (!this.options.createTestRun) {
    this.runId = this.options.runId;
    publishToAPI();
} else {
  axios({
    method: 'get',
    url: `${this.base}/get_runs/${this.projectId}`,
    headers: { 'Content-Type': 'application/json' },
    auth: {
        username: this.options.username,
        password: this.options.password,
    }
  })
    .then(response => {
      this.runId = response.data[0].id;
      publishToAPI();
    })
}

or even without get request, because, in case this.options.createTestRun == true you can create a test run and immediatelly assign it's ID to this.runId and use it here.

Am I right?

shifr commented 5 years ago

And looks like instead of using this.projectId you should use this.options.projectId everywhere.

mikelseverson commented 5 years ago

I'm also running into this

response.data[0].id does not match id configured within cypress.json

downgrading to 1.3.0 worked for me

kamcmt commented 5 years ago

The projectId in testrail.js is hardcoded as follows :

    this.projectId = 2;

I changed the value to my actual projectId and this fixed the issue.

atjeff commented 4 years ago

For any newcomers to the project, this has been fixed. Should close it

anastasiiaols commented 3 years ago

Hi, it looks like part of this issue still reproduces for me. It always uses last TestRail runId instead of runId that I set in cypress.json. Downgrading the reporter to 1.3.0 fixed it, but it would be great to fix it in the new version as well. Thanks!

jprealini commented 3 years ago

@anastasiiaols How does your cypress.json look like?

anastasiiaols commented 3 years ago

@jprealini I currently switched to another similar reporter because of that issue, but as I remember I just copy-pasted example from the readme and added my values: https://github.com/skekauoha/salty-cypress-testrail-reporter#testrail-reporter-for-cypress. Everything worked fine except the latest TestRail runId was used instead of the one from "runId" value

jprealini commented 3 years ago

@anastasiiaols ok... I was curious because for what I can see in the plugin's code, if you want to pass your own RunID it's just a matter of setting the "createTestRun" option to false... not that I tried it myself. In fact, my scenario is different. I have a fixed TestRun for the whole release, and we are always hitting that same runId.. so in order to NOT have to hardcode it in the settings (I would have to hardcode the ID evertime a new release comes) I modified the "isRunToday" function so that it will call the TestRail API "get_runs" and return the only existing runID in the current project...

BTW.. did you stumble upon the issue that causes the last executed spec to NOT be published to TestRail? AND... which reporter are you using? I guess that if you didn't see that behavior I mentioned with the last spec not being published, I should try the one you are using

anastasiiaols commented 3 years ago

@jprealini Thanks for the details! We currently use autoset-status-cypress-testrail-reporter in our project and it also has the issue with the last spec not being published. My coworker added an extra empty test as a workaround for it. This is probably the issue of the original cypress-testrail-reporterpackage

jprealini commented 3 years ago

@anastasiiaols np... BTW, after a couple of days of tinkering and playing around, I was able to fix the "last spec" issue... Have a look in this repo I just created... https://github.com/juanpablorealiniB2B/str-cypress-testrail-reporter (STR stands for Single Test Run... you will find that I removed stuff like the option to create a test run from cypress, mainly because in my scenario I don't need that. We have just one test suite and one test run per project, so by just passing the project id I can retrieve testrun id to use for the api calls... Had to introduce some changes to how the testrail.js methods return the results, but it worked... (You need to use the "deasync" npm package) Hope it helps...

anastasiiaols commented 3 years ago

Thank you @jprealini! I will see if I can adapt your solution. BTW, did you update TestRail to version 7? If yes I'm curious if your reporter still works with the new version. It looks like they changed API a bit.