Add includeBuildNumberInTargetPath configuration parameter
#169
Conversation
src/main/resources/hudson/plugins/copyartifact/CopyArtifact/help-appendSrcNumberToTarget.html
Outdated
Show resolved
Hide resolved
|
I'd much prefer that there was a test that exercises the new code and confirms it works as expected. Would you be willing to add an automated test to confirm it? |
|
Yeap I can do that. Is there a test case I can refer to as reference?
Regards,
Allan
…On Sat, Jan 28, 2023, 00:33 Mark Waite ***@***.***> wrote:
I'd much prefer that there was a test that exercises the new code and
confirms it works as expected. Would you be willing to add an automated
test to confirm it?
—
Reply to this email directly, view it on GitHub
<#169 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA2JCEZE4GJQPZ2DIBVBNSDWUP2GLANCNFSM6AAAAAAUIMNKQQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
seems like a good match for something similar to what this new feature is doing. |
|
The parameter name is a bit misleading but I can't think of one better. Let me know if there are things that could improve this pull request, I'll gladly change. Thanks in advance. |
I agree that the parameter name is a bit misleading. While I was interactively testing it, I was surprised when the build number was used as the directory name. That seemed like "prepending" rather than "appending". Would it be clearer if it was named |
MarkEWaite
changed the title
|
Thanks Mark for the suggestion. I've updated the name of the parameter and the test case. |
MarkEWaite
changed the title
includeBuildNumberInTargetPath
MarkEWaite
changed the title
includeBuildNumberInTargetPathincludeBuildNumberInTargetPath configuration parameter
|
Thanks very much @allancth. The pull request is looking good. In future pull requests, you can simplify things for the maintainer if you create the pull request from a feature branch rather than using the master branch. When starting development on a fresh feature, sync your repository with the upstream repository and then create a new branch with Also in future pull requests, you can simplify things for the maintainer if you don't remove the pull request checklist that GitHub inserts into the pull request. That checklist reminds the maintainer of things to check and can remind you of things to do as well. |
|
Noted Mark. I'll make sure to do that in the future. Appreciate the advice
and guidance.
Cheers.
Regards,
Allan
…On Sun, Jan 29, 2023, 11:32 Mark Waite ***@***.***> wrote:
Thanks very much @allancth <https://github.com/allancth>. The pull
request is looking good.
In future pull requests, you can simplify things for the maintainer if you
create the pull request from a feature branch rather than using the master
branch. When starting development on a fresh feature, sync your repository
with the upstream repository and then create a new branch with git
checkout -b new-feature-name master
Also in future pull requests, you can simplify things for the maintainer
if you don't remove the pull request checklist that GitHub inserts into the
pull request. That checklist reminds the maintainer of things to check and
can remind you of things to do as well.
—
Reply to this email directly, view it on GitHub
<#169 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA2JCEZY2UYYCKN6QPT3ROTWUXQDXANCNFSM6AAAAAAUIMNKQQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Released as 684.vde867d759462 |
|
@allancth are you interested in adopting the copyartifact plugin? The plugin has been modernized enough that the work to be a maintainer is probably no more than an hour or two a month to review pull requests for dependency updates. |
|
Thanks @MarkEWaite. I am interested in adopting and be happy to be a maintainer for the plugin. I have not done anything like this before hence it would be helpful if there are guides I can use. |
|
There are guides that can help. The steps are described in "Adopt a plugin" where you send email to the Jenkins developers list saying that you'd like to adopt the plugin and submit a pull request to the permissions repository that will add yourself to the list of maintainers. You need to login to https://issues.jenkins.io with your Jenkins account and you need to login to https://repo.jenkins-ci.org with your Jenkins account. I'm happy to help with the steps if you encounter issues. The "improve a plugin" tutorial includes videos and steps that can help (though most are already done for this plugin). If you'd like more ideas for improvements, there is the "Contributing to Open Source" document |
| Include\ Build\ Number= |
There was a problem hiding this comment.
This will translate the strings to an empty string. Almost certainly not what you want.
There was a problem hiding this comment.
Thanks @daniel-beck . I saw that in the code review and wondered about it. When I searched through Jenkins core and saw a number of message properties that were assigned an empty value, I thought that it must be a pattern that caused the property to be assigned the value from the default language.
An example:
Another example:
Is the preferred pattern to leave the untranslated key out of the localized property file or is there a better way to handle it?
In this case, the best way to handle it may be to transition this plugin to use CrowdIn for its localization. That will allow translators to submit messages through the CrowdIn user interface rather than directly editing property files.
@allancth would you like to submit the pull request to remove the untranslated properties or would you prefer that I do it so that you can approve the change?
There was a problem hiding this comment.
@allancth I submitted:
If you approve and merge, it should result in a new release with a changelog that includes the bug fix.
| Include\ Build\ Number= |
#169 added empty translation strings. They will cause the two items to be shown as empty strings in the local language versions (German and Japanese). Better to remove the empty translation properties so that the English will be displayed.
|
Sorry Mark for the late reply and not able to submit a PR earlier. I have
approved the PR you've submitted. Thank you.
Regards,
Allan
…On Mon, Jan 30, 2023, 21:15 Mark Waite ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In
src/main/resources/hudson/plugins/copyartifact/CopyArtifact/config_de.properties
<#169 (comment)>
:
> +Fingerprint\ Artifacts=
+Include\ Build\ Number=
Thanks @daniel-beck <https://github.com/daniel-beck> . I saw that in the
code review and wondered about it. When I searched through Jenkins core and
saw a number of message properties that were assigned an empty value, I
thought that it must be a pattern that caused the property to be assigned
the value from the default language.
An example:
https://github.com/jenkinsci/jenkins/blob/a530a99926940cb37fd2f7b66e5c2f458254a710/core/src/main/resources/hudson/logging/LogRecorder/configure_fr.properties#L24
Is the preferred pattern to leave the untranslated key out of the
localized property file or is there a better way to handle it?
In this case, the best way to handle it may be to transition this plugin
to use CrowdIn for its localization. That will allow translators to submit
messages through the CrowdIn user interface rather than directly editing
property files.
@allancth <https://github.com/allancth> would you like to submit the pull
request to remove the untranslated properties or would you prefer that I do
it so that you can approve the change?
—
Reply to this email directly, view it on GitHub
<#169 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA2JCE3UP7GA4PQFDUBRII3WU65INANCNFSM6AAAAAAUIMNKQQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Add
includeBuildNumberInTargetPathconfiguration parameterThe new parameter includeBuildNumberInTargetPath accepts a boolean. When true, the build number of the source project will be included the target path. This is particularly useful when the selector is specific and the value is a permalink, e.g. lastSuccessfulBuild.