Comments (4)
A few ideas I've settled on.
- Don't return a stream. Why is it important for the user to see the text in real time anyways? All they really need to know is if it succeeded or failed. Anything else is superfluous.
- Return the exit code at the end of the stream. This has 2 side effects:
2a. Requires some kind of standard interface for the response (i.e. The build output is all the returned text except for the last line which is the status code they need to parse).
2b. Requires the user to manually parse the response and determine if the job passed or failed - (Undesirable) Return a job identifier that the user could call again to get the exit code. (undesirable since it's two requests and makes the server stateful. Statefulness is one of the core philosophy of this application). I think this could take two approaches with the first being the only real option since
3a. Return the job id to the user and as long as the job is running then the user can get the logs so far. This is less stateless because there isn't any permanent state that is being held and as soon as the job finishes that endpoint will no longer be valid
3b. (BAD IDEA) Return the job id to the user and they can look up running jobs or jobs that finished running. Technically docker is handling the state for us here. However, I think we might want to consider automatically cleaning up jobs after they run which means these logs won't be around. However, if there's ever a method devised to only clean up jobs on a regular basis this may be more feasible because the logs may still be around. However, we have to make it clear to the user that there is no guarantee there logs will still be around as they may have been cleaned up. This may be an option down the road after other basic features of the server are solidified since it doesn't technically make the server stateful since docker is handling the state. But it still is by relation.
Note that between 1 and 2 it may be a good idea to settle on a standard interface for a response anyways such as JSON. Of course with the first option it wouldn't be required. However, we already require JSON input for the interface so this may align better there. However, counter to that is another core philosophy of this project is simplicity for the user. Although it would align the input and output interfaces it would make things slightly less simple since the user may need to parse the JSON returned.
from conjob.
I think I will go with idea # 1.
It is the simplest solution to implement. It also simplifies the response to not being a stream which I think is not necessarily a requirement. It may be somewhat expected as a feature of a CI server but I think that could be a bit of a deep seated idea/antipattern that you need to watch your CI jobs output as it runs. Usually the only reason you are watching a build is if you are worried about it failing or there is some problem. Since all of these builds can be run all the same locally using the docker container then it should be very infrequent that you need to troubleshoot build issues on the build server itself rather than running them locally and troubleshooting that way. Plus it's not like you won't be getting your job output; it will just have to wait until the job finishes.
I think eventually it could be a feature to the server that can be specified with a flag set in the request. However, I think that will look something like option # 2 which also requires changing the format of the response likely to a json object with the log output and the exit code. The complicated part about this is figuring out how to augment the output stream.
from conjob.
I'd like to point out that this ticket evolved from the original purpose. It was initially intended for only figuring out what error codes to return in the header. Then when it was realized that we had no control over the header when streaming a response we needed to figure out how to solve that problem first. The second issue has been solved by the commit and explained by the last comment.
Next is to solve the problem of what http status code to return. After thinking about it during work to fix the other issue, I think that a 400 is a good code to return. The biggest issue here is that it doesn't necessarily identify the issue as something with the build itself (e.g. if the user provided a bad image name). However, I don't think we necessarily need an error code to signify where the problem happened between the server or container. So maybe that really isn't that big of a deal anyways.
For now I will at least go with returning a 400 when the build itself returns a non-zero exit code.
from conjob.
Closed by 3600bb9
Other relevant commits:
1b1ab37
from conjob.
Related Issues (20)
- Look into code linting/formatting and advanced code analysis tools
- /var/lib/sysbox doesn't seem to be cleaned up HOT 3
- Move DockerAdapter out of core.job into new core.adapter package
- Upgrade to Gradle 7 HOT 2
- Should we write dropwizard integration tests even though it doesn't seem to integrate with jqwik?
- Introduce jqwik property tests into acceptance tests
- Performance tests are inconsistent
- Investigate flakiness with JobRunnerTest's HOT 1
- Fix unit test JRE crash HOT 2
- Use PostBodyTask for admin config endpoint
- Consider disabling unattended upgrades HOT 2
- Report more informative error to user when same job is run concurrently with docker cache mounted
- Start service on boot HOT 4
- Look for tools to look for out of date dependencies (and possibly update them)
- Is it problematic that docker-build-push docker cache is shared between projects?
- Remove docker references from alt-env HOT 2
- Look into testspace.com for publishing test reports
- Reduce error output in unit tests HOT 1
- Use of mutation testing in conjob - Help needed
- Fix integration test failure HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from conjob.