Hello everyone!
"""
Monday, first of July-.I'm finishing with the tests in a module was 0000, I think great, this is run correctly. After the tests I decided to send the commit with the last part missing, they had done 02:00 am, I have to finish this tomorrow I have a meeting with the mentors, I thought. Ready finished task, what comes next.
After the meeting there are tasks to be done and my mind is already headed towards a new direction.
I solve some of the issues and I put myself with the central objective of the project, to incorporate travis to the pyafipws project. Again in my mind I think, -well this is easy I generate the file .travis.yml some tests and ready continuous integration run in the repository. . . It had been a week and I was still doing tests, collecting data and seeing what was the best way for Travis to work with the project. There were important points that had not taken into account which were generating conflicts for the deployment, was a constant error, error, failed... then automatically activate travis notifications mail, not only see that it not work, but now also remind me this by mail. I deactivate the option, it is a useful tool to know how the constructions are working.
A first problem occurred when trying to use the certificate with the key to generate the access ticket for the Afip servers, to generate at least the TA(access ticket) for the tests to work since they are made to interact with the test servers of Afip. Without TA, there is no test.
To test, I added the certificate and the key to the directory, for this I had used one of the web service tests of afip the client wsbfev1.
Result, empty access ticket!
Obviously this is returned when the ticket can not be generated, the causes can be varied.
well, but the idea was that both the certificate and the RSA key were not within the repo. Then I see the possibility of using the environment variables that travis offers from the configuration of its web API.
This generated a problem in pyafipws, since the content is used for the ticket request as a file, not as a variable, in order to use it in this way, for now we must extract the environment variable and generate the necessary files, a modification is made in the test for use with the variables.
Result, empty access ticket !.
Well, what is happening?
How are you constructing travis and how are the variables returned in the construction of the virtual machine?
Well for this travis has an explicit notes on how to place it if they have special characters.
But if there are spaces like the ones he takes and the spaces he takes but which are line breaks ('\ n') good for this my mentor @reingart had some very good suggestions to handle it.
Result, empty access ticket!
Then I start to doubt the travis environment variables and perform simple tests, they work correctly. I perform tests to adjust how the variables are returned and the result
expected for the tests to work.
Good results are achieved the variable returns the expected file in the construction.
Result, empty access ticket!
But hey, it was a breakthrough, travis was giving me back what I needed.
A question that arose was if the AFIP servers had origin detection and if they were not from Argentina
there they were blocked, let's know where the servers of travis, amazon, googlecloud ...?
I change the test and start using the module that generates the step-by-step access ticket in the methods
and I find something interesting. At the beginning of the process a tra that is an XML that is dated is required
of generation and expiration in the range of one hour (example: generated at 12:00 and expires at 13:00)
Immediately I think clearly what is the schedule that this generates in the VM travis, correct the server of travis has a different schedule. This is configured in the travis file and the correct time in the generated tra.
Result, empty access ticket!
We must continue investigating.
In the build of travis when I get to the loginCMS test which is the method that returns the TA,
everything in light red, until that moment I had configured the .yml with the tests for versions 3.5, 3.6, 3.7, 3.8 of python in three empty access ticket meeting !, one version appeared in red but it was the TA! how I had configured the test to show me what I returned and not the assert (example: assert TA == <anything>). Then I perform the test to test the status of the servers of afip, this time configured with the expected response and EUREKA .</anything>
Three constructions with empty access ticket and one in green with PASSED test.
Now why was this happening ... and there I agreed, that when I was making the adaptation for cryptography in the test response of the AnalyzeCertified method I saw that this is dated on 07-13-2019, what a coincidence? Maybe this was not the problem itself. When I told my mentor that they were no longer able to carry out the tests he said there was a problem with that then he was going to generate an exclusive certificate for the project because the same certificate can not be used at the same time to require an TA, he has to see a time of 10 minutes. The access ticket gives you a 12-hour use but once generated it can not be used again from another place until after 10 minutes.
Of course a 10-minute lapse in time, the other constructions fail, the servers do not authorize it, the first one asks for access, the rest do not obtain.
Well to test this I remove python test versions and leave only one.
I start to try the other tests with the modifications and excellent everything in green except for some issues. It was perfect the things working well .
It was Thursday, google mail with reminder of second evaluation, that it was being evaluated and that the mentors had to go see the PR and that it was not useful to send everything last moment.
I start to think and this was correct PR only 2 in the first week, but from the tasks of the meeting the rest of the tasks performed only in commits to the issues because if it generated the PR I did not know how they would affect the mergeability of these since they were changes that went through the whole project I was missing the PR of cryptography
I remember that at the time I had not done it because one of the mentors asked me for the module test to check the functionality of the new unit. I generate the PR of the dependency, a DRAFT PR with the content of the evolution of travis in the project, the PR of the file .travis.yml.
Remembering this, I think, -we test if it works in travis, replacing the old one with the new WSAA that is the generator of access tickets if it does not work, all the tests are dropped.
Perfect performance! I start generating the settings of the test_wsaa and it occurs to me to try the module without the dependency so I remove cryptography from requirements.txt
Result, empty access ticket!
Well I will wait, because another problem is that I use the same certificate on my local machine so if I do a test on my machine if 10 minutes have not passed, the seim problem is generated in the construction of travis.
20 minutes later I try again, the same result.
One of the advantages that pyafipws offers is that without having the M2Crypto or cryptography dependencies installed, it gives the possibility to generate the TA directly from OpenSSL.
I test on my local machine without cryptography and it didn't work. I realized that the error was in declaring a variable that acted as a condition, since this was taken as true when the dependency was installed but there was no contrary condition for this to execute correctly.
Why had this happened?
I remembered, I tried both parts separately (with and without dependency) and when I did the test together I had only done it with the dependency installed, in my mind it was left, - everything works correctly. With which I realized that a new test is never too much.
After so much suffering I began to want to travis, it is a great tool now this branch helps me to test everything I am going to send in both commits and PR.
And now I'm going to deploy a web services simulator, I'll also continue with the tests in the process.
"""
Regards and Good Week!