Re: jenkins-bom-2.329.pom no longer on repo.jenkins-ci.org

[José Lamas Ríos]

Thanks for the quick reply and the link.

I'll watch that thread.



On Friday, March 4, 2022 at 9:01:59 PM UTC-3 Mark Waite wrote:

> On Friday, March 4, 2022 at 4:55:56 PM UTC-7 José Lamas Ríos wrote:
>
>> Recent builds for genexus-plugin on ci.jenkins.io 
>> <https://ci.jenkins.io/blue/organizations/jenkins/Plugins%2Fgenexus-plugin/activity>
>>  
>> are failing because this dependency can't be resolved.
>>
>>
> The artifact repository repo.jenkins-ci.org has a full disc that may be 
> causing the issue.  See 
> https://groups.google.com/g/jenkins-infra/c/usFq7mMOTWQ/m/sCpyXJj3AgAJ 
> for details
>
> Mark Waite
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/e544c90c-2153-4025-88d5-6abfddf7a340n%40googlegroups.com.

jenkins-bom-2.329.pom no longer on repo.jenkins-ci.org

[José Lamas Ríos]

Recent builds for genexus-plugin on ci.jenkins.io 

 
are failing because this dependency can't be resolved.

Eg: on 
https://ci.jenkins.io/blue/organizations/jenkins/Plugins%2Fgenexus-plugin/detail/master/134/pipeline

[2022-03-04T23:39:09.616Z] [INFO] Scanning for projects...
[2022-03-04T23:39:48.361Z] [WARNING] The artifact 
xml-apis:xml-apis:jar:2.0.2 has been relocated to 
xml-apis:xml-apis:jar:1.0.b2
[2022-03-04T23:39:58.364Z] [ERROR] [ERROR] Some problems were encountered 
while processing the POMs:
[2022-03-04T23:39:58.364Z] [ERROR] Non-resolvable import POM: Could not 
find artifact org.jenkins-ci.main:jenkins-bom:pom:2.329 in 
repo.jenkins-ci.org (https://repo.jenkins-ci.org/public/) @ 
org.jenkins-ci.plugins:plugin:4.33, 
C:\Jenkins\workspace\Plugins_genexus-plugin_master@tmp\m2repo\org\jenkins-ci\plugins\plugin\4.33\plugin-4.33.pom,
 
line 123, column 19

Is this expected? 



-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/0244b8ac-9837-4d5b-811e-cb46a3c78cdan%40googlegroups.com.

Re: Automated plugin release failing on 'check interesting categories' step

[José Lamas Ríos]

Thank you all for your comments and help.

tl;dr: seems to be working now (last PR merge resulted in a new release)

FTR: some notes about what I did:

   1. Last night I manually ran the workflow to see if it made any
   difference that there was already a release draft.
  1. It created an additional release draft
  
https://github.com/jenkinsci/genexus-plugin/releases/tag/untagged-1934fa52b049ad8ace3d
  in addition to the previous one at
  
https://github.com/jenkinsci/genexus-plugin/releases/tag/untagged-7aa3d1fa5d120e7a8b1a.
  Both are shown as created Dec 10 2021, though it might simply be
a problem
  with the web site logic fetching the date for release with that
'next' name
  and getting the data for the old one (name is not unique).
   - The check interesting categories did return true, the release was
  triggered, although it failed for some reason I could not understand (the
  build shows as success but at the end it says the "Process completed with
  exit code 4".
  
https://github.com/jenkinsci/genexus-plugin/runs/5326733932?check_suite_focus=true
  - An additional release dr
   2. Then this morning tried:
  - Deleted the release drafts mentioned above
  - Also deleted that old 'next' release that was actually published.
  - Fired the workflow again (
  
https://github.com/jenkinsci/genexus-plugin/runs/5333860868?check_suite_focus=true
  )
  - A new release draft was created, which again shows the Dec 10 2021
  date and references the commit at that time (
  
https://github.com/jenkinsci/genexus-plugin/commit/a6dbd90e9ec54c3b9ca1e3f9888cc8a2e9f1ebc5
  )
  - The package was created at
  
https://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/genexus/294.v9475d0bc3504/
  but then the release failed with a 403 error when trying to
transfer it to
  maven.jenkins-ci.org.
   3. Later:
  - Delete the latest release draft.
  - Delete the git tag 'next'
  - Fired workflow (
  https://github.com/jenkinsci/genexus-plugin/actions/runs/1899441015)
  - The new draft was correctly created (no date, no tag)
  
https://github.com/jenkinsci/genexus-plugin/releases/tag/untagged-298c04db8291690da8f9
  - Release failed again with same 403 error.
   4. Last:
  - Merged a PR from dependabot (Bumps actions/setup-java from 2.5.0 to
  3) https://github.com/jenkinsci/genexus-plugin/pull/30
  - CD was automatically fired and completed without errors (
  https://github.com/jenkinsci/genexus-plugin/actions/runs/1899746441)
  resulting in
  - New release published
  https://github.com/jenkinsci/genexus-plugin/releases/tag/296.v7ea4debe37c9



On Fri, Feb 25, 2022 at 6:05 AM Alex  wrote:

> Looks like others had the same idea like me and got it working with a PAT:
> https://github.com/release-drafter/release-drafter/issues/1081#issuecomment-1050099868
>
> Or locally like it does work for you.
>
> timja...@gmail.com schrieb am Freitag, 25. Februar 2022 um 09:36:38 UTC+1:
>
>> Weirdly if I run all the steps locally from the GitHub action I'm getting
>> the right results =/
>>
>>
>> https://github.com/jenkinsci/jenkins-infra-test-plugin/runs/5330785488?check_suite_focus=true
>>
>> On Thu, 24 Feb 2022 at 23:37, Alex  wrote:
>>
>>> I got it working by exchanging the GitHub token in the workflow with a
>>> PAT:
>>> https://github.com/jenkinsci/purge-build-queue-plugin/commit/3e0e709bf62ec15a84d5bf4e2e81a98ace7b79bf
>>>
>>> I guess, GitHub either changed or broke something (both I'm currently
>>> unaware of), because the regular GH token suffices and grants read/write
>>> perms to all scopes, unless you change the workflow permission to read only
>>> for content, but that doesn't apply here.
>>> Alex schrieb am Donnerstag, 24. Februar 2022 um 23:57:39 UTC+1:
>>>
>>>> To amend my comment on the dark-theme-plugin PR, I got the action
>>>> somewhat of working by wiping the additional drafts and keeping one that
>>>> covers all.
>>>> I'm using release-drafter via GitHub actions outside of Jenkins too and
>>>> have repositories with several drafts with different entries, so I'm not
>>>> sure whether that is an actual issue with CD or GH actions/release-drafter
>>>> itself.
>>>> However, I didn't make it as far as Tim, because the "release" step
>>>> fails with a 403 on deployment for me. That failure creates a new draft and
>>>> we're basically back at step one.
>>>>
>>>>
>>>> timja...@gmail.com schrieb am Donnerstag, 24. Februar 2022 um 23:18:30
>>>> UTC+1:
>>>>
>>>>> We were just discussing this here:

Re: Automated plugin release failing on 'check interesting categories' step

[José Lamas Ríos]

Maybe unrelated but I've just noticed that the release draft 
<https://github.com/jenkinsci/genexus-plugin/releases/tag/untagged-1934fa52b049ad8ace3d>
 
that was just created and is listed as the most recent one but shows a Dec 
10 2021 date...

There is in fact another release 
<https://github.com/jenkinsci/genexus-plugin/releases/tag/next> on that 
date that is not in draft state but (probably due to some error on my part) 
got published while keeping the 'next' tag / name.

I'll later try renaming or deleting the old release and check if that fixes 
the problem. 




On Thursday, February 24, 2022 at 6:52:46 PM UTC-3 José Lamas Ríos wrote:

> Hi, 
>
> I'm having problems with the automated release workflow for genexus-plugin 
> <https://github.com/jenkinsci/genexus-plugin>.
>
> For instance, this CD run at 
> https://github.com/jenkinsci/genexus-plugin/runs/5325279945
>
> After the successful build it gets to create the release draft, but then 
> seems to fail at finding it with an interesting category, so the release is 
> not fired.
>
> The draft release was created at 
> https://github.com/jenkinsci/genexus-plugin/releases/tag/untagged-1934fa52b049ad8ace3d
>  
> and running these commands on my terminal does seem to work:
>
> McJLR:~jlr$ RESULT=$(gh api /repos/jenkinsci/genexus-plugin/releases | jq 
> -e -r '.[] | select(.draft == true and .name == "next") | .body' | egrep 
> "$INTERESTING_CATEGORIES" || echo 'failed')
>
> McJLR:~ jlr$ echo $RESULT
>
> ##  Bug fixes
>
>
> Any ideas?
>
> Thanks in advance,
>
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/c742b7c1-e2e2-456a-a6ab-d2a56f76fb36n%40googlegroups.com.

Automated plugin release failing on 'check interesting categories' step

[José Lamas Ríos]

Hi, 

I'm having problems with the automated release workflow for genexus-plugin 
.

For instance, this CD run at 
https://github.com/jenkinsci/genexus-plugin/runs/5325279945

After the successful build it gets to create the release draft, but then 
seems to fail at finding it with an interesting category, so the release is 
not fired.

The draft release was created 
at 
https://github.com/jenkinsci/genexus-plugin/releases/tag/untagged-1934fa52b049ad8ace3d
 
and running these commands on my terminal does seem to work:

McJLR:~jlr$ RESULT=$(gh api /repos/jenkinsci/genexus-plugin/releases | jq 
-e -r '.[] | select(.draft == true and .name == "next") | .body' | egrep 
"$INTERESTING_CATEGORIES" || echo 'failed')

McJLR:~ jlr$ echo $RESULT

##  Bug fixes


Any ideas?

Thanks in advance,




-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/00fd5ecb-518c-43a1-85a5-39398a49effcn%40googlegroups.com.

Re: Support for experimental (beta) releases on JEP-229

[José Lamas Ríos]

On Tuesday, November 9, 2021 at 10:47:29 PM UTC-3 Jesse Glick wrote:

> On Tue, Nov 9, 2021 at 3:06 PM José Lamas Ríos wrote:
>
>> Regarding 'conceptually compatible' I'm not sure whether you refer to 
>>> automatic deployment in general or to the way it's implemented in this case
>>>
>>
> Well, any scheme by which the update center pattern-matches on plugin 
> version numbers.
>
> I think the most natural way to support JEP-229 in the experimental update 
> center would be:
>
>- Give `jenkins-maven-cd-action` an option to leave releases in draft 
>after deployment.
>- Patch `isAlphaOrBeta` in the UC code to look for a GitHub release 
>matching the version number of the plugin. If it exists, and it is 
>currently in draft, treat the plugin like it is beta.
>
>
I think that although this might work, it would be confusing. An 
experimental (alpha or beta) release is not the same thing as a release in 
draft state. I think 'draft' refers to the release process (we are 
preparing a release, and although we have a draft we haven't completed it 
yet), while 'experimental' refers to the content of the release (we did 
release it, but its content and functionality may not be fully validated).

Making the UC code be aware of the GitHub releases and consider their draft 
or final states also seems to be an undesirable coupling of so far 
independent mechanisms.

GitHub does allow marking releases as in draft state and also, as a 
separate concept, optionally marking them as 'pre-release', which in their 
words is a way "to notify users that the release is not ready for 
production and may be unstable".
https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository

I may be wrong, but still fail to see why the use of JEP-229 may not be 
compatible with the publication of experimental releases, that can be a) 
exposed in a separate update center as usual and b) marked as "Pre-release" 
when published on GitHub.

In my previous experiment I had tried adding "-beta" to the  in 
the pom file and that failed when archiving the artifacts because it was 
using  instead  when looking for them. I think that 
changing that code to use  (ie: not taking as granted that version 
== changelist) would be more appropriate, but as an alternative I tried 
this:

   - Reverted the pom to declare ${changelist}
   - Added instead the beta qualifier to the changelist.format in 
   maven.config (ie: -Dchangelist.format=%d.%s*-beta* )
   - Forced a new release.

The release was successful. As expected, it's not listed in the regular 
update center (https://updates.jenkins.io/update-center.json) but it does 
appear on the experimental one (
https://updates.jenkins.io/experimental/update-center.json) as 
version 252.356d312df76f-beta

It also got published as a GitHub release using the same version 
identifier. However, since it wasn't declared as "pre-release", it showed 
there as "Latest", as a regular release.

I later manually fixed that through the web UI, but it would be nice that 
the jenkins-maven-cd-action also recognized 'beta' or 'alpha' qualifiers in 
the version identifier to take care of that, the same way it's done for the 
update center.

I think this would be easy to achieve by modifying its run.sh as follows:

gh api -X PATCH -F draft=false -F name=$version -F tag_name=$version 
/repos/$GITHUB_REPOSITORY/releases/$release
[[ $version = *alpha* || $version = *beta* ]] && isAlphaOrBeta=true || 
isAlphaOrBeta=false
gh api -X PATCH -F draft=false -F name=$version -F tag_name=$version -F 
prerelease=$isAlphaOrBeta /repos/$GITHUB_REPOSITORY/releases/$release

Does it make sense? It does seem simple and good enough for me, but I may 
be missing something.




-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/fc88f856-64dd-4e8c-a83c-730e2abae372n%40googlegroups.com.

Re: Support for experimental (beta) releases on JEP-229

[José Lamas Ríos]

On Sunday, November 7, 2021 at 8:07:46 PM UTC-3 Jesse Glick wrote:

> The system is not designed to support marking releases as beta. I am not 
> sure such a requirement is even conceptually compatible with the style of 
> automatic deployment.
>

Regarding 'conceptually compatible' I'm not sure whether you refer to 
automatic deployment in general or to the way it's implemented in this 
case, using incremental versions in particular.
 

> If such a requirement is common,
>

Personally I find it practical to have a separate release channel for beta 
releases and its corresponding discovery and update simplicity for end 
users: just change the URL to be able to see possible updates and apply 
them through the UI), but not sure if it may be considered as common. 

The update channels currently list 1874 plugins and comparing the 
experimental at https://updates.jenkins.io/experimental/update-center.json 
with the standard  at https://updates.jenkins.io/current/update-center.json 
there are right now differences for around 30 plugins.
 

> I think it would need to be done differently, as a true promotion: the 
> same version number and binary artifact would initially be published to the 
> experimental update center and then subsequently marked somehow as eligible 
> for the main update center.
>

FWICS, the update center currently checks the version to exclude artifacts 
containing "alpha" or "beta" from the regular update center:
https://github.com/jenkins-infra/update-center2/blob/1690b80d6a92489c1be9ba51105c47ba4f3e5d9d/src/main/java/io/jenkins/update_center/MavenArtifact.java#L88

It also checks for "SNAPSHOT" and "JENKINS" to ignore those:
https://github.com/jenkins-infra/update-center2/blob/e72cebfa594356c94f0c40d310c956058439e576/src/main/java/io/jenkins/update_center/BaseMavenRepository.java#L56

But if keep adding qualifiers to versions is a problem, then yes, it would 
require moving those marks (and the update center code) somewhere else. 
 

>
> Consider skipping the experimental update center and gating new features 
> behind a flag that users can opt into.
>

Yes, feature flags may help on some particular scenarios but not for many 
beta processes.
 

> If only a select few users actually run the experimental releases to begin 
> with, they can also obtain them from the incrementals repository—you can 
> turn off automatic releasing of the default branch and trigger releases 
> only with the manual workflow, while every successful trunk build will be 
> deployed to the incrementals repository where it can be downloaded on 
> demand for beta testing.
>

Agree, that would be a work-around, but it does penalize both the CD 
experience for the developer and the discover and update experience for 
beta testers.


 

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/e270f5ea-d286-45d9-9833-1b3ade248e48n%40googlegroups.com.

Re: Support for experimental (beta) releases on JEP-229

[José Lamas Ríos]

The pattern is at 
https://github.com/jenkins-infra/pipeline-library/blob/67b51a985f803bf2ed6bab67fa6764e4d7dfc956/vars/buildPlugin.groovy#L233
archiveArtifacts artifacts: "**/*$changelist/*$changelist*",

Should it be changed to this?

archiveArtifacts artifacts: "**/*$version/*$version*",

For instance, I can see that 
at 
https://github.com/jenkins-infra/pipeline-library/blob/67b51a985f803bf2ed6bab67fa6764e4d7dfc956/vars/infra.groovy#L306
 
it does use $version instead of $changelist

Given that the install is done based on $version it does seem that the 
archive should use $version too (rather than assuming $version == 
$changelist), but then again I'm not sure wether it's ok to change the 
version definition the way I'm doing it, or how experimental releases 
should be done.




On Friday, November 5, 2021 at 8:06:58 PM UTC-3 José Lamas Ríos wrote:

> Hi,
>
> I've switched to the CD implemented on JEP-229 for genexus-plugin (
> https://github.com/jenkinsci/genexus-plugin) and couldn't find a way to 
> publish experimental releases, as I used to do based on what's described at 
> https://www.jenkins.io/doc/developer/publishing/releasing-experimental-updates/
>
> First tried including "-beta" in the changelist property in pom.xml
>
> 99-beta-7-SNAPSHOT
>
> The first release was successful
> ( 
> https://github.com/jenkinsci/genexus-plugin/releases/tag/250.v1b0d8b7f9a4a 
> ) but got published as version 250.v1b0d8b7f9a4a , that is, not including 
> the "-beta" qualifier and thus became available at the standard update 
> center ( https://updates.jenkins.io/update-center.json )  instead of the 
> intended experimental one ( 
> https://updates.jenkins.io/experimental/update-center.json )
>
> Then I tried moving the "-beta" qualifier to the  itself (see 
> https://github.com/jenkinsci/genexus-plugin/commit/fbb5777ce84f5c8a4dfe51ddd5dc3166fc85e06e#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8
>  
> )
>
> As you can see on the build log at 
> https://ci.jenkins.io/blue/rest/organizations/jenkins/pipelines/Plugins/pipelines/genexus-plugin/branches/master/runs/115/log/?start=0
>  
> the -beta qualifier was present when installing the genexus.hpi file:
>
> [2021-11-05T22:08:42.395Z] [INFO] --- 
> maven-install-plugin:3.0.0-M1:install (default-install) @ genexus ---
> [2021-11-05T22:08:42.395Z] [INFO] Installing 
> C:\Jenkins\workspace\Plugins_genexus-plugin_master\target\genexus.hpi to 
> C:\Jenkins\workspace\Plugins_genexus-plugin_master@tmp\m2repo\org\jenkins-ci\plugins\genexus\251.vfbb5777ce84f-beta\genexus-251.vfbb5777ce84f-beta.hpi
> [2021-11-05T22:08:42.395Z] [INFO] Installing 
> C:\Jenkins\workspace\Plugins_genexus-plugin_master\target\genexus-251.vfbb5777ce84f-beta.pom
>  
> to 
> C:\Jenkins\workspace\Plugins_genexus-plugin_master@tmp\m2repo\org\jenkins-ci\plugins\genexus\251.vfbb5777ce84f-beta\genexus-251.vfbb5777ce84f-beta.pom
> [2021-11-05T22:08:42.395Z] [INFO] Installing 
> C:\Jenkins\workspace\Plugins_genexus-plugin_master\target\genexus.jar to 
> C:\Jenkins\workspace\Plugins_genexus-plugin_master@tmp\m2repo\org\jenkins-ci\plugins\genexus\251.vfbb5777ce84f-beta\genexus-251.vfbb5777ce84f-beta.jar
> [2021-11-05T22:08:42.395Z] [INFO] Installing 
> C:\Jenkins\workspace\Plugins_genexus-plugin_master\target\genexus-sources.jar 
> to 
> C:\Jenkins\workspace\Plugins_genexus-plugin_master@tmp\m2repo\org\jenkins-ci\plugins\genexus\251.vfbb5777ce84f-beta\genexus-251.vfbb5777ce84f-beta-sources.jar
> [2021-11-05T22:08:42.395Z] [INFO] Installing 
> C:\Jenkins\workspace\Plugins_genexus-plugin_master\target\genexus-javadoc.jar 
> to 
> C:\Jenkins\workspace\Plugins_genexus-plugin_master@tmp\m2repo\org\jenkins-ci\plugins\genexus\251.vfbb5777ce84f-beta\genexus-251.vfbb5777ce84f-beta-javadoc.jar
>
> But then later, when trying to archive it as artifact, it failed to find 
> it because it didn't expect it to contain that "-beta" qualifier:
>
> [2021-11-05T22:09:38.560Z] Archiving artifacts [2021-11-05T22:09:39.220Z] 
> java.lang.InterruptedException: no matches found within 1
>
> [...]
> [2021-11-05T22:09:39.220Z] No artifacts found that match the file pattern 
> "**/*251.vfbb5777ce84f/*251.vfbb5777ce84f*". Configuration error? 
> Is publising experimental releases supported? I'm not sure I'm doing it 
> the way it's supposed to be done...
>
> That "**/*${changelist}/*${changelist}*" pattern does include a trailing 
> wildcard after the filename, so I guess the problem might be fixed adding a 
> wildcard after the folder too (that is, changing the pattern to 
> ""**/*${changelist}*/*${changelist}*"") ?
>
> Thanks in advance for any advice,
>
> Regards,
>
> -- 
> jl

Support for experimental (beta) releases on JEP-229

[José Lamas Ríos]

Hi,

I've switched to the CD implemented on JEP-229 for genexus-plugin 
(https://github.com/jenkinsci/genexus-plugin) and couldn't find a way to 
publish experimental releases, as I used to do based on what's described at 
https://www.jenkins.io/doc/developer/publishing/releasing-experimental-updates/

First tried including "-beta" in the changelist property in pom.xml

99-beta-7-SNAPSHOT

The first release was successful
( 
https://github.com/jenkinsci/genexus-plugin/releases/tag/250.v1b0d8b7f9a4a 
) but got published as version 250.v1b0d8b7f9a4a , that is, not including 
the "-beta" qualifier and thus became available at the standard update 
center ( https://updates.jenkins.io/update-center.json )  instead of the 
intended experimental one ( 
https://updates.jenkins.io/experimental/update-center.json )

Then I tried moving the "-beta" qualifier to the  itself 
(see 
https://github.com/jenkinsci/genexus-plugin/commit/fbb5777ce84f5c8a4dfe51ddd5dc3166fc85e06e#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8
 
)

As you can see on the build log 
at 
https://ci.jenkins.io/blue/rest/organizations/jenkins/pipelines/Plugins/pipelines/genexus-plugin/branches/master/runs/115/log/?start=0
 
the -beta qualifier was present when installing the genexus.hpi file:

[2021-11-05T22:08:42.395Z] [INFO] --- maven-install-plugin:3.0.0-M1:install 
(default-install) @ genexus ---
[2021-11-05T22:08:42.395Z] [INFO] Installing 
C:\Jenkins\workspace\Plugins_genexus-plugin_master\target\genexus.hpi to 
C:\Jenkins\workspace\Plugins_genexus-plugin_master@tmp\m2repo\org\jenkins-ci\plugins\genexus\251.vfbb5777ce84f-beta\genexus-251.vfbb5777ce84f-beta.hpi
[2021-11-05T22:08:42.395Z] [INFO] Installing 
C:\Jenkins\workspace\Plugins_genexus-plugin_master\target\genexus-251.vfbb5777ce84f-beta.pom
 
to 
C:\Jenkins\workspace\Plugins_genexus-plugin_master@tmp\m2repo\org\jenkins-ci\plugins\genexus\251.vfbb5777ce84f-beta\genexus-251.vfbb5777ce84f-beta.pom
[2021-11-05T22:08:42.395Z] [INFO] Installing 
C:\Jenkins\workspace\Plugins_genexus-plugin_master\target\genexus.jar to 
C:\Jenkins\workspace\Plugins_genexus-plugin_master@tmp\m2repo\org\jenkins-ci\plugins\genexus\251.vfbb5777ce84f-beta\genexus-251.vfbb5777ce84f-beta.jar
[2021-11-05T22:08:42.395Z] [INFO] Installing 
C:\Jenkins\workspace\Plugins_genexus-plugin_master\target\genexus-sources.jar 
to 
C:\Jenkins\workspace\Plugins_genexus-plugin_master@tmp\m2repo\org\jenkins-ci\plugins\genexus\251.vfbb5777ce84f-beta\genexus-251.vfbb5777ce84f-beta-sources.jar
[2021-11-05T22:08:42.395Z] [INFO] Installing 
C:\Jenkins\workspace\Plugins_genexus-plugin_master\target\genexus-javadoc.jar 
to 
C:\Jenkins\workspace\Plugins_genexus-plugin_master@tmp\m2repo\org\jenkins-ci\plugins\genexus\251.vfbb5777ce84f-beta\genexus-251.vfbb5777ce84f-beta-javadoc.jar

But then later, when trying to archive it as artifact, it failed to find it 
because it didn't expect it to contain that "-beta" qualifier:

[2021-11-05T22:09:38.560Z] Archiving artifacts [2021-11-05T22:09:39.220Z] 
java.lang.InterruptedException: no matches found within 1

[...]
[2021-11-05T22:09:39.220Z] No artifacts found that match the file pattern 
"**/*251.vfbb5777ce84f/*251.vfbb5777ce84f*". Configuration error? 
Is publising experimental releases supported? I'm not sure I'm doing it the 
way it's supposed to be done...

That "**/*${changelist}/*${changelist}*" pattern does include a trailing 
wildcard after the filename, so I guess the problem might be fixed adding a 
wildcard after the folder too (that is, changing the pattern to 
""**/*${changelist}*/*${changelist}*"") ?

Thanks in advance for any advice,

Regards,

-- 
jlr


 

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/faac5382-c55b-46e2-ac88-7c0fa700b22en%40googlegroups.com.

Re: [Digester/ACTION REQUIRED] Release needed for plugins: teamconcert, vs-code-metrics, BlameSubversion, javatest-report, vss, genexus, synergy, config-rotator, harvest, cmvc to avoid them to break

[José Lamas Ríos]

Hi,

Apologies for the delay. I've just merged the PR for GeneXus plugin and
released its 1.10 version for it.

Thanks!


On Tue, Jun 1, 2021 at 7:44 PM Baptiste Mathus  wrote:

> Hi,
>
> (in CC the Jenkins developers ML)
>
> You're receiving this email because your email appeared in "git log" for
> one of the Jenkins plugins listed in the email subject.
> This plugin is *going to start breaking with next Jenkins weekly without
> an action*.
>
> If you still consider yourself a maintainer of this plugin, please keep
> reading and better yet answer this thread.
> If not, you can either tell us this plugin is up for adoption, or ignore.
>
>
> See https://github.com/jenkinsci/jenkins/pull/5320 for the PR for each
> plugin.
>
> Each PR needs to be merged AND released.
>
> Thank you
>
> -- Baptiste
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CABFj%2BgbyhxT4ccm%3DdoAepv327g4QnbDHsV1cjz93r1815-b_ew%40mail.gmail.com.

Re: SCM plugin not appearing as SCM option in project configuration

[José Lamas Ríos]

On Friday, November 24, 2017 at 10:47:53 AM UTC-3, José Lamas Ríos wrote:
>
>
> I've set breakpoints in the constructor, and the newInstance() and 
> getDisplayName() methods, but one of them gets hit.
>

Sorry, meant to say "but *none* of them get hit"
 

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/a3b6ccd9-51bd-4cf9-9ab9-2218e2d3bd81%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: SCM plugin not appearing as SCM option in project configuration

[José Lamas Ríos]

Hi Stephen, thanks for your help

On Friday, November 24, 2017 at 5:13:45 AM UTC-3, Stephen Connolly wrote:
>
>
>
> Override getDisplayName() and return a name... otherwise it is “invisible” 
> and cannot be selected.
>

Yep, I do have an override returning a string. Here's the entire 
DescriptorImpl class..

@Extension
public static class DescriptorImpl extends 
SCMDescriptor {

@Override
public boolean isApplicable(Job project) {
return true;
}
   
public DescriptorImpl() {
super(GeneXusServerSCM.class, null);
load();
}

@Override
public SCM newInstance(StaplerRequest req, final JSONObject 
formData) throws FormException {
return super.newInstance(req, formData);
}

@Override
public String getDisplayName() {
return "GeneXus Server";
}

@Override
public boolean configure(StaplerRequest req, JSONObject formData) 
throws FormException {
// Save configuration
save();
return super.configure(req, formData);
}

}

I've set breakpoints in the constructor, and the newInstance() and 
getDisplayName() methods, but one of them gets hit.

BTW, the entire project is available here if you want to take a closer look:
https://drive.google.com/open?id=1GNQDH4klYvHfCrmy-NFs6HSjeQqqalfe
 

>
> Are you following the implementation guide in scm-api 
> https://github.com/jenkinsci/scm-api-plugin/blob/master/docs/implementation.adoc
>  because 
> if I missed mentioning that it would be great if you could file a PR to 
> update the docs
>
>
Yes, I'm following that and also these:

https://wiki.jenkins.io/display/JENKINS/Plugin+tutorial#Plugintutorial-PluginImplapproach
https://wiki.jenkins.io/display/JENKINS/Writing+an+SCM+plugin
https://wiki.jenkins.io/display/JENKINS/SCM+plugin+architecture

Anyway, I'll re-read the implementation guide trying to find something I 
may have overlooked.

Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/939bb514-1bbf-4dc0-af5b-405882a63a3e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

SCM plugin not appearing as SCM option in project configuration

[José Lamas Ríos]

Hi,

Newbie here, newbie on Jenkins and even newbie on Java :)

I'm trying to write a new SCM plugin.

// com.genexus.gxserver/GeneXusServerSCM.java
public class GeneXusServerSCM extends SCM implements Serializable{

[...]

@Override
public DescriptorImpl getDescriptor() {
return (DescriptorImpl) super.getDescriptor();
}

@Extension
public static class DescriptorImpl extends 
SCMDescriptor {

@Override
public boolean isApplicable(Job project) {
return true;
}
   
public DescriptorImpl() {
super(GeneXusServerSCM.class, null);
load();
}

[...]

}

I can see my plug-in appear as installed on 
http://localhost:8080/jenkins/pluginManager/installed but don't see it as 
an option on the Source Code Management section of a project configuration 
(ie: http://localhost:8080/jenkins/job/GXserverProjectTest/configure).

My project includes a config.jelly 

// com.genexus.gxserver.GeneXusServerSCM/config.jelly










It only includes a simple 'Label' for now, but as I said above it doesn't 
even appear as an available SCM option ("None" and "Subversion" do appear).

I guess I'm missing some very basic thing, I've been looking at SVN and TFS 
implementations, but couldn't figure it out.

Any hint? How does Jenkins gets the list of available SCMs? Do I have a 
chance to debug that code?

Thanks in advance,



-- 
JLR

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/a156f150-cd96-4d59-b54e-70d17f7b1963%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.