I am open to other suggestion, I guess it goes to notice or debug
3 replies
I will be working next on reading from package.json... What project type shall we call it? 😅
Please let me know if I shall work on anything else (eg. breaking change fix) first
2 replies
@adi10hero:matrix.org I think you're going in the right direction! The most important thing right now is adding all the support for the different types of projects.
You shouldn't have too many PRs open at once, so let's get the "BREAKING CHANGES" footer closed this week.
The first check in period is 12 July. At the start of next week, let's get a feel for how much work is left in this first milestone period. I think you're on track to have all the types done, and their tests. I think, mentors chime in here with votes, after you have the other project types finished, at the end of next week, you will be able to release a new version of the plugin which will be fully downloadable from the Jenkins plugin website. Having something useable and demoable is going to be a great milestone achievement. What does everyone think?
That way the week of the evaluations, you can do documentation and even write a blog post (I think we're required to do that for Jenkins GSoC this year, so with the fully released version of the plugin, you won't have to worry about it)
1 reply
I'll send a link out before hand
@garethjevans: A new contributor wants to work on package.json issue, he's asking whether he can work on it, tagged me as well, I had just created a new branch, did not really work anything, what should be done?
Hi everybody ! I'm the "new contributor wants to work on package.json issue" :wink:
I'm a "newcomer contributor" but a senior Java developer. In my job I'm in charge of develop Jenkins pipeline as code (groovy in shared lib).
Glad you accept my contribution, I done a similar feature in a Jenkins pipeline (thus with Groovy code).
To summarize I'm using the npm version command to "compute" next version.
If it's ok for you I open a PR to discuss of the best way to do the feature (not necessarily by using npm version command, it was just an idea :wink:)
I'm a "newcomer contributor" but a senior Java developer. In my job I'm in charge of develop Jenkins pipeline as code (groovy in shared lib).
Glad you accept my contribution, I done a similar feature in a Jenkins pipeline (thus with Groovy code).
To summarize I'm using the npm version command to "compute" next version.
If it's ok for you I open a PR to discuss of the best way to do the feature (not necessarily by using npm version command, it was just an idea :wink:)
cool :smiley: , I'll create the PR as soon as possible.
Another question : I'did not found any coding rule or .editorconfig to format code. Is it free or do you use external standards (like Oracle conventions for example), I think for new contributors (like me) it's a good think to have these kind of resources / documentation.
I don't know if I have to create an issue for this "internal" feature proposal or initiate a dedicated PR.
Another question : I'did not found any coding rule or .editorconfig to format code. Is it free or do you use external standards (like Oracle conventions for example), I think for new contributors (like me) it's a good think to have these kind of resources / documentation.
I don't know if I have to create an issue for this "internal" feature proposal or initiate a dedicated PR.
@adi10hero:matrix.org With the coding phase 1 coming to a close soon, we want to make sure that you can have a new release of the plugin out for the initial review. Is there anything we can help you with?
Actually, yes, testing is taking time, it will be really helpful if I get an example of what is needed (my weekend + Monday got wasted due to bad health), once the basic testing framework is in place, rest PRs would come quickly
6 replies
hi, I've pushed the PR (still in progress, in case you want to take a look) : jenkinsci/conventional-commits-plugin#52. If I understand it's just the reading of the version number that it be done, not the compute of the next version ? There is few code comments, it's my comprehension of the code :wink:
5 replies
Hi all,
PR is ready to review : jenkinsci/conventional-commits-plugin#52
I think when PR will be approve I can do the same dev for Chart.yaml (issue #20).
PR is ready to review : jenkinsci/conventional-commits-plugin#52
I think when PR will be approve I can do the same dev for Chart.yaml (issue #20).
Would merge, waiting for a mentor to go over it once (just to be sure)
Finallyy... Mocking Successful! Thank you so much @garethjevans, your example PR really helped (and I learnt a lot too, research + trial and error took around 5 hours yesterday, after your PR it was done under 1 hour :) )
@adi10hero:matrix.org If it's ok for you, you can assign me the #20 issue in order to I start the conception / dev :)
3 replies
@all, I would be working on reading current version from Makefile, doing some research on it, I have some doubts..
- Makefile doesn't really has a convention for writing
version, it can beVERSION=orVERSION:=I also saw,version:=(lower case) - version may or may not be "static", variables might be used to denote the version, for example"
version := $(command)
Handling 1. is easy, but for 2, I did not find any CLI command to print out (evaluate) the version, there are some which change the Makefile to add a
print section to the Makefile and then run make print to evaluate version.
2 replies
For such a case, would it make sense to:
- Copy the Makefile
- Add the print section
- get the version
- delete the copy Makefile
In my proposal, I had put using
j4make but it is not what I expected it to be :(
@mentors, There's only one issue left in Milestone1 (reading from helm.yaml), @philippart-s is working on it, so I started with "reading from python's setup.cfg" issue (#48), does it make sense to continue working on it or am I expected to do something else (other than filling the feedback form) as Phase 1 is ending?
hello @kwhetstone actually, I made the python PR, I had also pushed codestyle fixes (150+) in another PR (which showed 0 errors) but I guess it was using some old config.
Would it okay for us to merge the python PR and other PRs as well and then I can finally fix the remaining codestyle errors and do the release? :)
PR #65 is ok now, I exclude the snakeyaml dependency from the jakson dependency. I assume that in a real Jenkins that the snakeyaml version is the same that the workflow-aggregator dependency